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Abstract 


Assuring  and  evolving  concurrent  programs  requires  understanding  the  concurrency- 
related  design  decisions  used  in  their  implementation.  In  Java-style  shared-memory 
programs,  these  decisions  include  which  state  is  shared,  how  access  to  it  is  regulated, 
and  the  policy  that  distinguishes  desired  concurrency  from  race  conditions.  Source 
code  often  does  not  reveal  these  design  decisions  because  they  rarely  have  purely  local 
manifestations  in  the  code,  or  because  they  cannot  be  inferred  from  code.  Many  pro¬ 
grammers  believe  it  is  too  difficult  to  explicate  the  models  in  ordinary  practice.  As  a 
result,  this  design  intent  is  usually  not  expressed,  and  it  is  therefore  generally  infeasible 
to  assure  that  concurrent  programs  arc  free  of  race  conditions. 

This  thesis  is  about  a  practicable  approach  to  capturing  and  expressing  design  in¬ 
tent,  and,  through  the  use  of  annotations  and  composable  static  analyses,  assuring  con¬ 
sistency  of  code  and  intent  as  both  evolve.  We  use  case  studies  from  production  Java 
code  and  a  prototype  analysis  tool  to  explore  the  costs  and  benefits  of  a  new  annotation- 
based  approach  for  expressing  design  intent.  Our  annotations  express  “mechanical” 
properties  that  programmers  must  already  be  considering,  such  as  lock-state  associ¬ 
ations,  uniqueness  of  references,  and  conceptual  aggregations  of  state.  Our  analyses 
reveal  race  conditions  in  a  variety  of  case  study  samples  which  were  drawn  from  li¬ 
brary  code  and  production  open  source  projects. 

We  developed  a  prototype  tool  that  embodies  static  analysis  techniques  for  assuring 
consistency  between  code  and  models  (expressed  as  code  annotations).  Our  experience 
with  the  tool  provides  some  preliminary  evidence  of  the  practicability  of  our  approach 
for  ordinary  programmers  on  deadlines.  The  dominant  design  consideration  for  the 
tool  was  adherence  to  the  principle  of  “early  gratification” — some  assurance  can  be 
obtained  with  minimal  or  no  annotation  effort,  and  additional  increments  of  annotation 
arc  rewarded  with  additional  increments  of  assurance. 

The  novel  technical  features  of  this  approach  include  (1)  regions  as  flexible  ag¬ 
gregations  of  state  that  can  cross  object  boundaries,  (2)  a  region-based  object-oriented 
effects  system;  (3)  analysis  to  track  the  association  of  locks  with  regions,  (4)  policy 
descriptions  for  allowable  method  interleavings,  and  (5)  an  incremental  process  for 
inserting,  validating,  and  exploiting  annotations. 
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Chapter  1 


Introduction 


Reasoning  about  concurrent  programs  is  a  challenge  for  both  programmers  and  software  tool  de¬ 
signers:  What  data  is  shared?  Is  it  accessed  safely?  What  locks  should  be  held  when  the  data  is 
accessed?  A  fundamental  aspect  of  the  challenge  of  concurrency  is  that  the  information  needed  to 
understand  a  concurrent  program  is  non-local — that  is,  there  is  no  single  place  in  the  code  where 
there  is  an  expression  of  the  design  commitments  necessary  to  ensure  safe  concurrency.  Because 
many  of  these  design  commitments  arc  not  expressed,  programmers  developing  and  evolving  con¬ 
current  code  may  be  more  likely  to  wander  from  the  original  design,  resulting  in  concurrency- 
specific  errors,  such  as  race  conditions,  deadlock,  and  failure  to  comply  with  threading  conventions 
of  library  API’s.  To  make  matters  worse,  when  errors  occur,  they  may  be  hard  to  localize.  They  may 
appear  to  be  manifest  in  portions  of  code  that,  in  fact,  correctly  apply  the  discipline.  Concurrent 
programs  arc  thus  hard  to  understand  and  reason  about,  hard  to  evolve,  and  hard  to  assure,  test,  and 
debug. 


1.1  Missing  Design  Information 

The  absence  of  explicit  concurrency-related  design  information  means  that  programmers  risk  intro¬ 
ducing  hard-to-find  concurrency-errors  during  maintenance  and  evolution  because  they  arc  forced 
to  infer  or  make  guesses  about  non-local  design  attributes  such  as  lock-state  association,  aliasing, 
locking  responsibility,  and  lock  order.  For  any  given  lock,  for  example,  the  programmer  must  guess 
what  is  the  state  it  protects.  Inspection  of  the  extant  critical  sections  defined  by  that  lock  can  suggest 
which  variables  arc  protected  by  the  lock.  But  what  about  the  objects  referred  to  by  those  variables? 
Is  their  state  separately  protected?  Arc  the  references  unaliased,  and  if  so  is  the  uniquely  referenced 
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object  considered  to  be  paid  of  the  same  abstraction  as  the  referring  object?  What  about  state  that 
is  sometimes  accessed  in  a  critical  section,  but  sometimes  not:  is  it  meant  to  be  protected  by  a  lock 
and  the  program  is  unsafe,  or  arc  the  accesses  from  critical  sections  only  coincidental?  For  any  pair 
of  locks,  in  what  order  should  they  be  acquired  to  prevent  deadlock? 

For  any  particular'  segment  of  state,  source  code  analysis  can  help  the  programmer  deduce  this 
information  from  the  code,  but  it  requires  inspecting  all  the  portions  of  the  code  that  might  access 
that  state.  Such  comprehensive  inspection  is  necessary,  for  example,  because 

•  A  thread  that  accesses  shared  data  outside  of  a  critical  section  may  produce  data  races  with 
threads  that  correctly  access  the  data  from  within  a  critical  section,  rendering  the  attempts  at 
mutual  exclusion  of  the  correctly  implemented  threads  irrelevant. 

•  Object  orientation  distributes  conceptual  resource  state  across  multiple  objects.  To  effectively 
reason  about  thread-safety  due  to  object-orientation,  the  programmer  must  have  a  good  un¬ 
derstanding  of  the  design  intent  behind  class  and  object  relationships,  in  particular  whether 
the  state  stored  across  many  objects,  of  possibly  different  classes,  is  meant  to  be  aggregated 
into  a  single  abstraction. 

•  A  resource  cannot  always  be  reasoned  about  in  the  absence  of  its  clients  because  the  correct 
usage  of  the  resource  may  depend  on  the  design  goals  of  its  client.  For  example,  the  length, 
get,  and  remove  methods  of  j  ava .  util .  Vector  do  not  interfere  with  each  other  because 
the  implementation  of  Vector  uses  locks.  But  two  threads  sharing  a  Vector  must  coordinate 
at  a  higher  level — one  thread  removing  an  element  can  interfere  with  another  thread  iterating 
over  a  vector. 

This  non-local  character  of  lock-state  design  information  frustrates  the  later  recovery  of  program¬ 
mer  design  intent.  Comprehensiveness  also  goes  against  the  practices  of  using  libraries  and  com¬ 
ponent-based  architectures  where  the  intent  is  to  simplify  program  understanding  by  introducing 
abstraction  boundaries.  In  addition,  it  is  frequently  the  case  that  the  internals  of  libraries  and  compo¬ 
nents  are  hidden  from  the  client  programmer,  making  it  difficult  to  perform  comprehensive  analysis, 
particularly  when  objects  are  passed  through  abstraction  boundaries. 

Programmers  must  also  guess  about  whether  a  reference  is  meant  to  be  aliased,  particularly  in 
object-oriented  programs.  For  a  programmer  to  know  that  a  reference  to  an  object  is  unaliased  is 
highly  advantageous.  Programmers  frequently  make  this  assumption,  for  example,  when  building 
data  structures  from  aggregations  of  objects  because  it  allows  the  structure  to  be  destructively  al¬ 
tered  or  objects  to  be  reused  internally  without  affecting  clients  of  the  data  structure.  In  a  concurrent 
program,  the  encapsulation  that  may  be  obtained  by  uniqueness  simplifies  reasoning  about  safety 
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because  it  limits  the  segments  of  code  that  might  alter  the  uniquely  referenced  object.  If  we  know 
that  a  variable  holds  a  unique  reference  to  an  object  then  we  know  that  that  object  cannot  be  refer¬ 
enced  concurrently  except  through  the  encapsulation.  Thus  it  is  enough  to  rely  on  the  encapsulation 
to  protect  access  to  the  reference  and  the  referenced  object. 

Unfortunately,  because  aliasing  is  a  non-local  design  attribute,  reasoning  about  whether  a  ref¬ 
erence  intended  to  be  unaliased  is  actually  unaliased  is  non-trivial,  and  the  property  is  easy  to  in¬ 
validate  accidently.  Inspection  of  the  code  can  provide  clues  about  the  intent,  but,  once  again,  all 
uses  of  the  field  must  be  examined,  and  it  is  difficult  to  determine  if  an  alias  might  inadvertently  be 
“leaked.”  A  programmer  trying  to  understand  the  code  and  its  design  during  an  inspection  process 
might  think  that  such  leaks  are  intentional  and  thus  assume  the  reference  is  intended  to  be  aliased. 
Explicit  expression  of  whether  a  variable  is  intended  to  be  unaliased  would  aid  a  programmer’s 
understanding  during  maintenance  and  evolution,  and  would  also  enable  static  analysis  to  assure 
that  usage  is  consistent  with  intent.  Because  aliasing  is  such  a  fundamental  design  choice  for  data 
structures,  analyses  assuring  the  correct  use  of  a  variable  not  intended  to  be  aliased  would  be  funda¬ 
mental  for  supporting  additional  analyses  related  to  other  design  commitments,  such  as  lock-state 
association. 

In  general,  programming  languages  and  processes  do  not  facilitate  the  capture  of  program  design 
information  in  ways  amenable  or  appreciable  by  practicing  programmers.  Nor  do  they  readily 
provide  the  means  to  assure  that  captured  design  information  is  consistent  with  source  code  and  vice 
versa.  As  a  result,  design  information  may  be  lost  or  out  of  sync  with  the  reality  of  the  code.  Missing 
or  incorrect  design  information  impedes  explicit  assurance  of  the  safety  of  concurrent  programs, 
because  the  properties  to  assure  arc  obscured,  as  well  as  their  safe  evolution.  For  example,  absent 
explicit  knowledge  of  how  existing  state  is  intended  to  be  protected,  that  is,  associated  with  locks,  it 
is  unclear  how  to  manage  the  addition  of  new  state.  Is  the  new  state  to  be  covered  by  existing  locks, 
or  does  it  require  a  fresh  association? 

1.1.1  Kinds  of  Software  Information 

Assurance  and  safe  evolution  of  concurrent  programs  would  be  easier  if  we  could  document  the 
missing  design  information  so  that  it  is  readily  available  to  the  programmer.  Examples  include 
aliasing,  the  extent  of  different  segments  of  shared  state,  associations  between  locks  and  state,  and 
which  locks  a  method  assumes  the  caller  holds.  By  missing  we  mean  “not  easily  inferable  from  the 
source  code.”  We  focus  on  one  aspect  of  software  design  information:  models  that  describe  intended 
properties  of  an  implementation.  More  specifically,  we  distinguish  between  three  kinds  of  software 
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(a)  public  synchronized  void  enqueue (  Object  o  )  { 

if (  size  <  capacity  )  { 
buf  [tail]  =  o; 

if (  ++tail  ==  buf . length  )  tail  =  0; 
size  +=  1; 

l1 

(b)  “The  lock  on  the  queue  object  should  be  acquired  before  accessing  any  of  its  fields” 

(c)  “tail  should  always  point  to  the  next  free  location  in  the  array  referenced  by  buf” 

Figure  1.1:  Examples  of  software  information:  (a)  source  code,  (b)  design  intent,  and  (c)  design 
rationale. 


information: 

1.  The  source  code  of  the  software  artifact.  Source  code  is  the  ground  truth  with  respect  to 
what  the  program  actually  does.  While  analyses  can  be  used  to  infer  design  information  from 
source  code,  code  is  not  in  general  fully  self  revealing,  as  we  shall  discuss  below. 

2.  The  design  intent  behind  the  source  code.  These  arc  the  policies  that  an  implementation 
should  adhere  to.  As  discussed  above,  design  intent  is  rarely  captured,  and  even  less  often 
kept  consistent  with  code.  This  research  is  about  providing  a  means  and  incentive  to  capture, 
maintain,  and  exploit  concurrency -related  design  intent.  Design  intent  formally  describes 
models  that  source  code  should  adhere  to. 

3.  The  design  rationale  behind  the  policies  and  models  that  guide  implementation.  Design  ra¬ 
tionale  is  the  why  behind  the  what  of  the  design  intent.  We  arc  not  attempting  to  capture 
rationale. 

Consider,  for  example,  the  method  in  Figure  1.1(a)  taken  from  a  typical  Java  implementation 
of  a  queue.  The  actuality  of  implementation  is  that  the  method  enqueue  executes  with  the  lock 
on  the  queue  object  held,  and  accesses  the  fields  size,  capacity,  tail,  and  buf,  as  well  as 
indexing  into  the  array  referenced  by  buf.  The  source  code  is  consistent  with  the  design  intent — 
locking  model — that  the  lock  on  the  queue  object  should  be  acquired  before  accessing  any  of  its 
fields.  We  can  document  this  design  intent  by  adding  the  formal  annotation  “@lock  QLock  is 
this  protects  Instance”  to  the  declaration  of  the  class.  This  intent  is  based,  in  paid,  on 
the  representation  invariant  that  tail  should  always  point  to  the  next  free  location  in  the  array 
referenced  by  buf.  This  invariant  is  paid  of  the  rationale  that  we  do  not  attempt  to  capture. 

Less  obvious  is  the  design  intent  behind  the  array  referenced  by  buf:  the  array  is  not  intended 
to  be  shared  with  any  other  objects.  More  specifically,  buf  holds  the  only  reference  to  the  array:  it 
is  considered  unshared  or  unaliased,  and  thus  the  entirely  separate  array  object  is  intended  to  be  paid 
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of  the  queue  object.  It  is  this  intent  that  allows  the  implementation  to  access  the  contents  of  the  array 
without  acquiring  additional  locks.  This  design  intent  can  be  formally  documented  by  annotating 
the  declaration  of  field  buf  with  “@unshared”  and  “©aggregate  []  into  Instance.”  These 
formal  annotations  modify  the  aliasing  model  with  which  source  code  must  be  consistent  as  well 
as  refine  the  model  of  object  state  used  by  the  previously  declared  locking  model.  These  aspects  of 
design  intent  arc  also  based  in  paid  on  the  unstated  representation  invariants  relating  the  contents  of 
the  array  to  the  values  of  the  head  and  tail  indices  that  make  up  the  design  rationale. 

The  boundary  between  what  is  source  code  and  what  is  design  intent  is  not  distinct.  It  is  in¬ 
fluenced,  for  example,  by  the  kinds  and  levels  of  abstraction  supported  by  the  target  programming 
language.  Consider  types  in  the  Java  and  C  programming  languages.  C  has  poor  support  for  en¬ 
capsulation:  in  spite  of  a  facade  of  type  definitions  and  structural  types,  data  is  still  treated  as  an 
aggregation  of  bytes,  as  evidenced  by  the  ubiquity  of  void*  and  char*  declarations.  Operations 
are  not  well  associated  with  the  data  structures  they  arc  intended  to  apply  to.  Elaborate  conventions 
on  the  usage  of  header  files  have  evolved  to  address  this  issue.  Java,  on  the  other  hand,  uses  classes 
to  strongly  type  and  encapsulate  the  structure  of  representations.  Class  types  define  the  legal  oper¬ 
ations  for  an  encapsulated  data  object.  Information  that  is  tacitly  captured  by  source  code  artifacts 
in  Java  must  be  explicitly  documented  in  C.  Thus  in  Java,  deliberate  and  accidental  attempts  to  cir¬ 
cumvent  encapsulation  boundaries  or  invoke  incorrect  operations  lead  to  compile-time  errors,  while 
in  C,  the  programmer  must  use  tools  such  as  Splint  [EL02]  and  Rational’s  Purify1  to  document 
formally  encapsulation-related  design  intent  and  to  check  consistency  between  code  and  intent. 

1.1.2  Recording  Design  Intent 

Similarly,  concurrency  is  not  well  abstracted  in  Java  (or  in  any  other  language  in  general  use). 
Therefore,  source  code  is  not  self -revealing  with  regards  to  concurrency-related  design  intent.  Con¬ 
tributing  to  this  problem  is  the  lack  of  generally  accepted  practical  intermediate  notations  and  meth¬ 
ods  for  expressing  and  reasoning  about  routine  concurrency  properties.  Notations  and  diagrams 
exist  and  are  widely  used  for  other  aspects  of  design  knowledge,  including  architecture  [GMW97], 
class  and  object  design,  sequencing,  and  state  transition  [BRJ99].  This  dissertation  thus  introduces 
formal  annotations  for  describing  models  of  concurrency-related  design  intent  such  as  lock-state 
associations,  state  organization  and  aggregation,  locking  responsibility,  and  allowable  execution 
interleavings.  Program  analyses  assure  that  code  and  expressed  design  intent  are  consistent,  im- 
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proving  assurance  of  code  safety  and  the  programmer’s  ability  to  safely  evolve  concurrent  code. 

We  recognize  that  producing  any  kind  of  source  code  annotation,  including  types  and  Java 
throws  clauses,  is  a  burden  for  programmers.  Programmers  have  shown,  however,  a  willingness  to 
accept  this  burden  by  adopting  languages  that  provide  sufficient  payback  for  the  annotation  effort. 
The  most  successful  example  of  a  program  annotation  scheme  is  types.  Programmers  arc  willing 
to  annotate  their  programs  with  types  because  it  helps  them  understand,  for  example,  what  arc  the 
appropriate  values  that  may  be  stored  in  a  variable  and  what  arc  the  operations  available  on  an 
object.  Static  compile-time  type  checking  helps  the  programmer  use  types  consistently  throughout 
the  program.  In  addition  to  being  rewarded  with  better  program  understanding,  the  programmer 
is  also  rewarded  with  type  safety,  such  as  the  assurance  that  no  floating  point  value  is  going  to  be 
interpreted  as  an  object  reference.  Other  successful  annotation  schemes  follow  this  reward  model, 
e.g.,  Hungarian  notation  [SH91],  Eiffel’s  design-by-contract  [Mey97],  Java’s  final  modifier,  and 
Java’s  throws  clause. 

Our  annotation  and  analysis  scheme  is  design  to  offer  similar  incentives.  We  expect  the  bur¬ 
den  of  introducing  an  annotation  to  be  low — that  is,  any  particular  annotation  is  relatively  easy  to 
understand  and  conceive.  Each  annotation  is  meant  to  provide  immediate  value  to  a  programmer 
by  answering  a  question  the  programmer  might  have  about  the  code.  A  dominant  design  consid¬ 
eration  for  our  approach  is  the  principle  of  "early  gratification” — some  assurance  can  be  obtained 
with  minimal  or  no  annotation  effort,  and  additional  increments  of  annotation  arc  rewarded  with 
additional  increments  of  assurance.  Guided  by  these  considerations,  we  have  developed  a  prototype 
tool  that  uses  static  analyses  to  assure  that  source  code  is  consistent  with  the  models  described  by 
our  annotations. 

1.1.3  Intent  vs.  Accident 

Like  type  information,  documented  design  intent  is  an  exploitable  contract  in  the  program's  API. 
Once  expressed,  it  is  thus  incumbent  on  the  source  code  to  be  consistent  with  the  intent.  As  paid  of 
the  API,  design  intent  is  meant  to  change  more  slowly  than  implementation,  and  hence  can  be  engi¬ 
neered  against  in  other  program  components.  Source  code,  as  mentioned  already,  reflects  the  truth 
with  respect  to  what  the  program  does.  It  is  sometimes  possible  to  infer  design  intent  from  code. 
For  example,  locks  typically  protect  something,  so  analysis  can  be  used  to  guess  the  association 
between  locks  and  state.  Heuristics  based  on  common  programming  patterns  could  be  used  to  infer 
relationships  between  objects.  Even  brute  force  can  be  used  to  exhaustively  try  all  possible  annota¬ 
tions  [FF01].  In  this  work,  however,  we  deemphasize  annotation  inference.  From  our  point  of  view. 
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inference  has  two  problems:  (1)  it  is  not  always  possible,  and  (2)  it  is  not  necessarily  desirable. 

The  expense  of  analysis  and  the  unavailability  of  source  code  arc  among  the  reasons  why  an¬ 
notations  might  not  be  inferable.  Most  interesting  program  properties  can  only  be  conservatively 
approximated  by  analysis  and  thus  we  cannot  rely  exclusively  on  inference  for  deriving  the  respec¬ 
tive  intent.  Many  of  the  properties  we  are  interested  in  are,  as  previously  discussed,  non-local,  that 
is,  manifest  across  multiple  software  components  and  abstractions.  Expensive  in  time  and  space 
whole -program  analyses  arc  needed  to  infer  information  in  such  situations.  In  addition,  code  may 
not  be  analyzable  because  it  is  part  of  a  library  distribution,  because  it  is  “native,”  i.e.,  written  in 
a  language  other  than  Java,  such  as  Java  AWT  peer  objects,  or  because  it  has  not  yet  been  written. 
Thus,  explicit  expression  of  design  intent  is  still  required  to  document  intent  at  API  boundaries. 

More  important  is  resolving  what  is  intent  from  what  is  accident.  That  is,  just  because  a  field 
happens  to  be  unaliased  in  the  implementation,  does  not  mean  that  the  field  is  guaranteed  to  be 
unaliased.  Inferred  models  will  necessarily  reflect  the  reality  of  the  source  code,  but  code  does 
not  necessarily  reflect  the  actual  design  intent.  Not  all  inferred  models  necessarily  correspond  to 
programmer  design  intent,  hence  the  use  of  the  word  intent.  Documenting  implementation  accident 
as  design  intent  unnecessarily  limits  program  evolution  because  of  the  contractual  nature  of  design 
intent.  Expressing  more  intent  than  is  necessary  thus  creates  more  implementation  obligations, 
and  possibly — depending  on  the  nature  of  the  design  intent — limits  implementation  flexibility.  The 
benefits  of  expressing  design  intent,  however,  arc  that  clients  arc  able  to  exploit  the  stated  behavior. 
In  an  earlier  example,  we  saw  how  the  knowledge  that  the  array  referenced  by  the  buf  field  is 
unaliased  simplified  the  overall  protection  of  the  queue’s  shared  state. 

Inference  of  formal  annotations  from  source  code,  if  performed  at  all,  must  thus  be  supervised 
by  the  programmer,  who  is  responsible  for  determining  what  is  design  intent  and  what  is  implemen¬ 
tation  accident. 

1.1.4  Assuring  Consistency  Between  Intent  and  Code 

Once  intent  is  documented,  maintenance  and  evolution  tasks  can  be  made  easier  because  static 
analysis  can  be  used  to  prevent  the  introduction  of  bugs  into  production  code  by  assuring  that 
source  code  is  consistent  with  documented  design  intent.  Thus  code-design  intent  consistency  can 
be  preserved  during  maintenance  and  evolution  which  becomes  focused  on  the  aggregate  of  code 
and  representations  of  models  of  design  intent. 

Analyses  will  fail  to  assure  the  annotated  program  when  stated  intent  and  source  code  are  in- 
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consistent,  that  is,  when  the  stated  intent  fails  to  accurately  reflect  the  actuality  of  the  code.  An 
assurance  failure  may  be  due  to  the  source  code  being  incorrect  and  unsafe,  in  which  case  consis¬ 
tency  can  be  restored  by  the  programmer  by  correcting  the  code.  Assurance  may  also  fail  because 
the  stated  intent  describes  an  incorrect  model  of  the  intended  program  behavior,  in  which  case  the 
programmer  needs  to  correct  the  model  describing  the  intent.  In  other  words,  the  assurance  pro¬ 
vided  is  of  consistency  of  the  code  with  the  models  of  intent. 

In  short,  concurrent  programming  is  difficult  because  design  information  describing  non-local 
properties  of  the  concurrent  program  is  missing  and  it  cannot  be  recovered  from  the  code  itself.  We 
believe  that  tools  to  assist  programmers  with  assuring  and  evolving  concurrent  programs  must  be 
informed  by  this  missing  concurrency-related  design  intent  and  be  able  to  maintain  the  consistency 
between  stated  intent  and  source  code  as  both  evolve. 


1.2  Concurrency-Related  Design  Intent 

Maintaining  consistency  between  stated  intent  and  source  code  is  a  fundamental  goal  of  this  work — 
otherwise  capturing  design  intent  in  source  code  is  no  more  useful  than  the  paper  design  documents 
that  age  on  the  programmer’s  shelf.  More  specifically,  this  dissertation  is  about  (1)  the  nature  of 
concurrency-related  design  knowledge;  (2)  the  consequent  failures  of  code  safety  that  can  result 
from  the  failure  to  express  the  missing  design  information;  (3)  a  practicable  approach  to  captur¬ 
ing  and  expressing  the  design  knowledge;  and  (4)  techniques  for  providing  assurance  that  code  is 
consistent  with  the  captured  intent  as  they  both  evolve. 

The  technical  approach  is  based  on  source  code  annotation  and  static  program  analysis.  A 
critical  success  factor  is  the  feasibility  and  adoptability  of  the  approach  for  practicing  software 
engineers.  A  working  programmer,  who  is  always  on  a  deadline  should  want  to  introduce  anno¬ 
tations  because  the  benefits  of  annotation  arc  both  useful  and  nearly  immediate.  We  therefore  ask 
the  programmer  to  record  design  intent  in  terms  of  properties  the  programmer  is  already  concerned 
about.  As  an  example  of  what  arc  these  properties,  and  as  anecdotal  evidence  that  programmers  are 
interested  in  them,  we  offer  this  excerpt  from  an  article  aimed  at  practicing  Java  programmers: 

One  of  the  most  important  behaviors  you  should  document — and  which  almost  never  is — is 
thread  safety.  Is  this  class  thread-safe?  If  not,  can  it  be  made  thread-safe  by  wrapping  calls 
with  synchronization?  Must  those  synchronizations  be  relative  to  a  specific  monitor,  or  will 
any  monitor  used  consistently  be  good  enough?  Do  methods  acquire  locks  on  objects  that  are 
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visible  from  outside  the  class?2 
Specifically,  we  use  annotations 

•  To  name  and  hierarchically  organize  the  state  of  a  program,  with  aggregates  that  may  span 
multiple  objects. 

•  To  describe  which  state  is  affected  by  a  method  (or  other  code  segment),  and  what  is  the 
nature  of  the  effects. 

•  To  describe  uniqueness  of  object  references. 

•  To  associate  locks  with  abstract  aggregations  of  state,  and  provide  names  for  the  locks. 

•  To  specify  which  methods  may  be  executed  concurrently. 

•  To  delineate  responsibility  for  acquiring  locks  ( e.g .,  caller  vs.  callee). 

1.2.1  Establishing  Safe  Concurrency 

We  can  interpret  code  safety  loosely  to  mean  that,  when  APIs  are  used  as  intended,  “nothing  bad 
happens.”  Concurrent  programming  errors  lead  to  erroneous  runtime  behavior  that  is  nondetermin- 
istic  and  hence  difficult  to  repeat  and  localize.  Discovery  and  prevention  of  these  programming 
errors  and  their  runtime  manifestations  arc  not  well  covered  by  existing  testing,  debugging,  and 
assurance  techniques.  We  believe  this  is  because  concurrent  programming  errors  arc  difficult  to 
identify  without  design  knowledge  regarding  the  locking  model.  Current  practice  does  not  provide 
the  incentive,  the  models,  or  a  language  for  programmers  to  record  this  information. 

Current  recommended  best  practice  for  safe  concurrency  is  to  avoid  using  it  [LeaOO].  Non¬ 
expert  programmers  are  advised  to  write  only  sequential  programs.  Even  experts  arc  often  advised 
to  use  concurrency  sparingly  because  it  is  too  hard  to  produce  large  and  correct  concurrent  programs. 
Consequently,  less  problematic  alternatives  to  concurrency  such  as  event-based  callbacks  have  been 
advocated  by  researchers  [Ous96].  Non-expert  programmers  can  produce  safe  concurrent  programs 
by  rigorously  adhering  to  programming  patterns,  such  as  those  described  in  [Bir91,  LeaOO,  BloOla]. 
By  following  well  established  programming  patterns  known  to  guarantee  thread  safety,  the  program¬ 
mer  may  feel  freed  from  having  to  design  the  locking  scheme  for  the  program.  But  the  programmer 
must  still  (1)  implement  the  pattern  correctly,  and  (2)  make  decisions  about  which  patterns  should 
be  followed.  Which  objects  should  be  aggregated  into  other  objects,  which  objects  should  be  im- 

2Brian  Goetz,  “I  have  to  document  THAT?”  http://www.ibm.com/developerworks/java/library/ 
j - j  tp0  82 1 . html. 
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mutable,  and  which  objects  should  be  shared  by  threads,  for  example.  Pattern-based  approaches 
break  down  when  the  programmer  needs  to  do  something  not  well  covered  by  an  existing  pattern. 
They  also  have  the  problem  that  they  trade  assurance  of  thread  safety  for  assurance  of  pattern  com¬ 
pliance,  and  for  assurance  of  the  safety  of  the  pattern  itself. 

Testing  and  debugging  techniques  that  work  for  sequential  programs  do  not  work  well  for  con¬ 
current  programs  because  of  the  nondeterminism  in  how  threads  may  interleave  their  executions 
[MH89].  Any  testing  approach  that  attempts  to  cover  all  possible  interleavings  quickly  becomes 
intractable.  Testing,  however,  is  with  respect  to  some  specification,  embodied  in  the  test  cases, 
and  thus  requires  knowledge  of  design  intent.  Concurrency  errors  arc  difficult  to  detect  using  code 
inspection  because  of  their  non-local  character.  But  once  again,  for  code  inspection  to  assure  the 
safety  of  the  code,  the  programmer  design  intent  must  be  known.  Source  level-debuggers  face 
an  additional  challenge:  reliably  replaying  a  race  condition  once  it  has  been  discovered.  This  is 
typically  done  by  recording  event  histories.  Unfortunately,  such  approaches  introduce  additional 
nondeterminism  into  the  program  being  debugged  because  they  cause  accesses  to  shared  state  that 
arc  not  present  in  the  original  program.  This  problem  has  been  identified  as  the  “Heisenberg  un¬ 
certainty  principle”  [LP85]  or  the“probe  effect”  [Gai85].  Applying  model  checkers  to  concurrent 
programs  can  be  effective  for  discovering  liveness  errors,  e.g.,  deadlock,  but  programs  must  first 
be  abstracted  to  produce  tractable  models  [CDH+00].  The  static  analyses  necessary  for  reducing 
the  size  of  the  models  benefit  from  knowledge  of  concurrency-related  design  intent,  such  as  lock- 
state  associations  and  state  aggregation,  although  this  intent  is  conservatively  inferred  in  practice 
[CorOO].  In  summary,  traditional  debugging  techniques  (1)  are  generally  foiled  by  the  nondetermin¬ 
ism  and  non-locality  inherent  in  concurrent  programs,  and  (2)  typically  require  the  knowledge  of 
concurrency-related  (and  other)  design  intent  to  be  fully  effective. 


1.3  Example:  Missing  Models 

Let  us  consider  as  an  example  the  models  of  design  intent  used  by  a  collection  of  Java  classes  from 
the  Jakarta  Log4j  logging  library  [Apa].  This  library  facilitates  debugging  by  providing  a  frame¬ 
work  for  components  to  write  messages  of  various  priorities  to  any  number  of  configurable  logging 
abstractions,  e.g.,  files,  consoles,  e-mail.  Implementations  of  the  Appender  interface  handle  the 
specific  logging  details.  Appenders  may  be  “chained”  together,  that  is,  an  appender  may  feed  into 
another  appender  to  achieve  additional  functionality.  A  sophisticated  logging  setup  could  adversely 
affect  the  performance  of  the  program:  the  appender  may  have  to  wait  for  network  or  disk  resources 
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that  arc  not  otherwise  required  by  the  program  being  examined,  for  example. 

A  multi-threaded  asynchronous  appender  implementation  AsyncAppender  shields  the  pro¬ 
gram  from  logger  latencies  as  much  as  possible — indeed,  concurrency  is  often  used  to  hide  and 
manage  latency  is  systems  programs.  When  placed  at  the  head  of  a  chain  of  appenders,  this  appen¬ 
der  decouples  the  logging  call  from  the  logging  action  by  insuring  that  the  logging  activity  executes 
in  a  thread  distinct  from  the  thread  executing  the  logging  request.  An  AsyncAppender  simply 
enqueues  a  logging  event  into  a  buffer  and  returns,  allowing  the  program  to  proceed  with  minimal 
interruption.  The  appender  shares  the  event  buffer  with  a  distinguished  dispatcher  thread.  This  dis¬ 
patcher  thread  removes  events  from  the  buffer  when  they  arc  available  and  passes  them  to  the  next 
appender  in  the  chain. 

In  this  example,  we  concern  ourselves  primarily  with  the  buffer  shared  between  the  Async¬ 
Appender  and  its  dispatcher  thread.  In  the  following,  we  examine  the  models  that  describe  the 
state,  the  aliasing  relationships,  and  the  locking  conventions  necessary  to  access  the  buffer  in  a 
thread-safe  manner.  We  also  describe  an  evolution  scenario  of  the  class  and  its  relationship  to  the 
design  models.  This  example  illustrates  (1)  the  non-local  nature  of  concurrent  design  knowledge; 
the  difficulties  of  (2)  recovering  the  design  knowledge  and  (3)  knowing  whether  the  intent  has 
been  correctly  understood  when  the  models  arc  not  explicit;  and  (4)  how  misunderstanding  can 
compromise  the  safety  of  a  class  when  it  is  evolved.  In  particular,  these  problems  arise  even  when 
designing  and  using  a  seemingly  small  and  simple  class. 

1.3.1  Class  BoundedFIFO 

The  class  BoundedFIFO,  shown  in  Figure  1.2,  taken  from  version  1.0.4  of  Log4j,  implements 
the  buffer  shared  between  AsyncAppender  and  its  dispatcher  thread.  An  instance  of  the  class  is  a 
circular  queue  represented  by  an  array  referenced  by  buf  and  head  and  tail  indices  first  and  next. 
An  instance  of  BoundedFIFO  is  shared  by  two  objects,  the  appender  object  and  the  dispatcher 
thread  object.  A  buffer  instance  may  be  accessed  by  code  executing  in  at  least  two  threads:  the 
dispatcher  thread  and  any  thread  from  the  rest  of  the  program  that  might  generate  logging  events — 
appenders  may  be  referenced  by  many  objects  in  many  threads.  Synchronization  among  the  clients 
of  BoundedFIFO  objects  is  necessary,  therefore,  to  avoid  potential  race  conditions. 

Two  concurrent  executions  of  put,  for  example,  could  result  in  the  loss  of  an  event,  because  the 
two  different  events  could  be  written  to  the  same  buf  location.  This  would  occur  if  both  threads 
executed  the  statement  on  line  24  that  reads  the  tail  index  before  either  thread  executed  the  statement 
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1  public  class  BoundedFIFO  { 

2  LoggingEvent  []  buf; 

3  int  numElts  =  0,  first  =  0,  next  =  0,  size; 

4 

5  /**  Create  a  new  buffer  of  the  given  capacity.  */ 

6  public  BoundedFIFO ( int  size)  { 

7  if (size  <  1)  throw  new  IllegalArgumentException ( ) ; 

8  this. size  =  size; 

9  buf  =  new  LoggingEvent [size] ; 

10  } 

11 

12  /**  Returns  <code>null</code>  if  empty.  */ 

13  public  LoggingEvent  get  ( )  { 

14  if  (numElts  ==  0)  return  null; 

15  LoggingEvent  r  =  buf  [first]  ; 

16  if (++first  ==  size)  first  =  0; 

17  numElts--; 

18  return  r; 

19  } 

20 

21  /**  If  full,  then  the  event  is  silently  dropped.  */ 

22  public  void  put (LoggingEvent  o)  { 

23  if  (numElts  !=  size)  { 

24  buf  [next]  =  o; 

25  if  (++next  ==  size)  next  =  0; 

26  numElts++; 

27  } 

28  } 

29 

30  /**  Get  the  capacity  of  the  buffer.  */ 

31  public  int  getMaxSize ( )  {  return  size;  } 

32 

33  /**  Get  the  number  of  elements  in  the  buffer.  */ 

34  public  int  length ()  {  return  numElts;  } 

35 

36  /**  Returns  <code>true</code>  if  the  buffer  was  empty  before  last  put  operation.  */ 

37  public  boolean  wasEmpty ( )  {  return  numElts  ==  1;  } 

38 

39  /**  Returns  <code>true</code>  if  the  buffer  was  full  before  the  last  get  operation.  */ 

40  public  boolean  wasFullO  {  return  numElts+1  ==  size;  } 

41 

42  /**  Is  the  buffer  full?  */ 

43  public  boolean  isFullO  {  return  numElts  ==  size;  } 

44  } 


Figure  1.2:  Class  BoundedFIFO. 
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on  line  25  that  increments  that  index.  Alternatively,  concurrent  calls  to  put  could  cause  an  Array - 
IndexOutOf  BoundsException  to  be  thrown: 

1.  Suppose  initially  next  ==  size-1. 

2.  The  first  thread  puts  its  new  element  in  the  array  by  executing  the  statement  on  line  24  and 
then  partially  executes  the  statement  on  line  25  by  incrementing  next  to  be  equal  to  size. 

3.  The  second  thread  also  executes  the  array  operation  on  line  24  using  the  new  value  of  next 
which  results  in  an  exception  because  next  is  now  beyond  the  end  of  the  array  referenced  by 
buf. 


1.3.2  The  State  of  BoundedFIFO 

Before  we  consider  how  clients  should  synchronize  their  access  to  a  BoundedFIFO  instance,  we 
need  to  answer  the  question  of  what  is  the  state  of  a  buffer  instance?  The  five  fields  of  the  class  arc 
obviously  paid  of  the  buffer’s  state.  Traditional  practice  and  the  races  described  above  suggest  that 
accesses  to  these  fields  need  to  be  coordinated.  Less  obvious,  perhaps,  is  that  the  array  referenced 
by  buf  should  also  be  considered  to  be  paid  of  the  state  of  the  buffer  because  each  buffer  has  its 
own  unaliased  array.  The  original  implementor  of  the  class  clearly  had  this  in  mind,  but  is  unlikely 
to  have  recorded  it  because  Java  does  not  provide  a  means  for  expressing  this  kind  of  information, 
and  thus  the  programmer  may  not  even  have  been  explicitly  aware  of  the  design  decision.  We  now 
have  two  elements  of  the  concurrency  model  of  the  BoundedFIFO  class  that  we  can  document: 

1.  The  field  buf  is  unshared ,  that  is,  it  refers  to  an  unaliased  object 

2.  The  state  of  a  buffer  is  all  its  fields  plus  the  state  of  the  uniquely  referenced  array. 

Describing  these  models  in  the  code  allows  our  tool  to  assure  the  source  code  of  BoundedFIFO 
is  consistent  with  the  programmer’s  intent.  If  the  implementation  is  changed  so  that  the  array 
is  allowed  to  be  aliased  then  assurance  will  fail.  This  assurance  is  critical  to  assuring  that  the 
buffer  class  is  thread-safe.  If  the  array  is  allowed  to  be  aliased,  the  techniques  used  by  clients  to 
synchronize  access  to  the  buffer  object  must  evolve. 

1.3.3  Protecting  BoundedFIFO 

Now  that  we  have  a  model  of  the  state  of  a  BoundedFIFO  object  we  can  consider  how  to 
synchronize  access  to  it.  The  existing  Log4j  clients  of  BoundedFIFO  arc  implemented  to  use  lock- 
based  synchronization  to  prevent  such  race  conditions.  Figure  1.3  reorganizes  code  from  several 
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public  class  PutterClient  {  ... 
private  final  BoundedFIFO  fifo; 

public  PutterClient (BoundedFIFO  bf,  ...)  {  fifo  =  bf;  ...  } 

public  void  putter (LoggingEvent  e)  { 
synchronized ( fifo)  { 
while ( fifo . isFull () )  { 

try  {  fifo.waitO;  }  catch  (InterruptedException  ie)  {  } 

} 

f if o . put (e) ; 

if (fifo . wasEmpty ( ) )  fifo . notify ( ) ; 


public  class  GetterClient  {  ... 
private  final  BoundedFIFO  fifo; 

public  GetterClient (BoundedFIFO  bf,  ...)  {  fifo  =  bf;  ...  } 

public  LoggingEvent  getter ()  { 
synchronized ( fifo)  { 

LoggingEvent  e ; 

while ( fifo . length ( )  ==  0)  { 

try  {  fifo.waitO;  }  catch  (InterruptedException  ie)  {  } 
e  =  f if o . get ( ) ; 

if ( f if o . wasFull ( ) )  f if o . notify ( ) ; 
return  e; 


Figure  1.3:  Canonical  clients  of  BoundedFIFO. 


Log4j  classes  into  canonical  producer  and  consumer  clients.  If  we  wish  to  add  another  client  or  to 
extend  the  functionality  of  BoundedFIFO  we  need  to  conform  to  the  locking  model  used  by  the 
existing  clients.  This  model  is  currently  undocumented ,  although  cursory  inspection  of  the  clients 
suggests  that  they  use  the  convention  of  locking  the  BoundedFIFO  object  before  invoking  any  of 
its  methods.  There  is  no  single  place  in  the  code  where  this  information  is  evident:  a  programmer 
trying  to  understand  BoundedFIFO  is  forced  to  deduce  this  information  by  inspecting  the  clients  of 
the  class. 

The  locking  model  for  BoundedFIFO  thus  requires  that  clients  of  a  BoundedFIFO  instance 
acquire  the  lock  on  that  instance  before  invoking  any  methods  on  the  object.  That  is,  the  state  of  the 
buffer,  as  delineated  by  the  model  given  above,  is  protected  by  the  lock  on  the  object  itself,  and  it  is 
the  responsibility  of  the  clients  to  acquire  that  lock  before  invoking  any  of  the  object’s  methods. 

In  the  absence  of  a  documented  model,  details  of  the  locking  convention  are  lost.  For  exam¬ 
ple,  is  there  anything  significant  about  using  the  BoundedFIFO  object  as  the  lock?  Must  the  lock 
be  acquired  before  invoking  any  method,  or  just  some  of  them?  Is  locking  to  protect  the  FIFO 
instance,  or  is  it  to  protect  the  clients  from  inconsistent  views  of  the  FIFO?  This  non-locality  not 
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/**  Resize  the  buffer  to  a  new  size.  If  the  new  size  is  smaller  than 
*  the  old  size  events  might  be  lost.  */ 
public  synchronized  void  resize (int  newSize)  { 
if (newSize  ==  size)  return; 

LoggingEvent []  tmp  =  new  LoggingEvent [newSize] ; 

//  we  should  not  copy  beyond  the  buf  array 
int  lenl  =  size  -  first; 

//  we  should  not  copy  beyond  the  tmp  array 
lenl  =  min(lenl,  newSize); 

//  er. .  how  much  do  we  actually  need  to  copy? 

//  We  should  not  copy  more  than  the  actual  number  of  elements, 
lenl  =  min (lenl,  numElts); 

//  Copy  from  buf  starting  a  first,  to  tmp,  starting  at  position  0,  lenl  elements. 
System. arraycopy (buf ,  first,  tmp,  0,  lenl); 

//  Are  there  any  uncopied  elements  and  is  there  still  space  in  the  new  array? 
int  len2  =  0 ; 

if ( (lenl  <  numElts)  &&  (lenl  <  newSize))  { 
len2  =  numElts  -  lenl; 
len2  =  min(len2,  newSize  -  lenl); 

System. arraycopy (buf ,  0,  tmp,  lenl,  len2) ; 

} 

this. buf  =  tmp; 
this. size  =  newSize; 
this. first  =  0; 
this. numElts  =  lenl+len2; 
this. next  =  this . numElts ; 

if (this. next  ==  this. size)  //  this  should  never  happen,  but  again,  it  just  might, 
this. next  =  0; 

} 


Figure  1.4:  Method  resize. 


only  complicates  our  understanding  of  the  program,  but  complicates  maintenance  as  well  because 
all  client  implementations  must  follow  the  same  convention  to  maintain  the  integrity  of  the  shared 
BoundedFlFO  object.  If  the  conventions  change,  then  all  the  clients  need  to  be  updated  to  insure 
safety. 

1.3.4  Evolution  and  Misunderstood  Intent 

The  actual  evolution  of  the  Log4j  library  provides  an  interesting  example  of  a  change  to  Bound¬ 
edFlFO  that  could  be  unsafe  if  the  locking  model  of  the  class  is  misunderstood.  Between  versions 
1.0.4  and  l.lbl  of  Log4j,  a  resize  method,  shown  in  Figure  1.4,  was  added  to  the  class.  As  the 
name  implies,  this  method  alters  the  capacity  of  the  buffer.  Unlike  the  other  methods  in  the  class, 
resize  is  synchronized,  meaning  that  the  implementation  runs  inside  a  critical  section  locked 
on  the  receiver  object,  i.e.,  the  BoundedFlFO  object  itself.  A  client  of  a  FIFO  object  does  not  have 
to  lock  the  FIFO  before  invoking  this  method,  and  indeed  updated  clients  of  BoundedFlFO  objects 
do  not  acquire  any  locks  before  invoking  it. 

The  implementation  of  method  resize  is  consistent  with  the  locking  model  for  the  class:  the 
lock  on  the  object  is  acquired  before  the  state  of  the  object  is  accessed.  But  the  overall  locking 
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model  evolves  to  indicate  that  resize  does  not  require  its  caller  to  acquire  the  lock  on  the  object. 
The  implementation  is  also  consistent  with  the  aliasing  model:  the  array  referenced  by  buf  remains 
unaliased,  even  though  it  may  be  a  different  array  object  after  resize  terminates.  Assurance  of  this 
consistency  requires  assuming  that  System,  arraycopy  does  not  produce  aliases  to  its  two  array 
parameters.  This  intent  is  recorded  by  annotating  those  two  parameters  as  being  “borrowed”  which, 
in  fact,  constrains  the  implementation  of  the  method. 

If  the  locking  model  for  the  class  had  been  misunderstood  by  an  author  of  a  client,  then  this 
use  of  the  resize  method  by  that  client  could  cause  a  race  condition.  That  is,  supposed  an  au¬ 
thor  of  a  client  misunderstood  the  intent,  for  example,  by  consistently,  but  incorrectly,  using  some 
other  object  as  the  lock  to  protect  a  BoundedFlFO  instance.  Now,  because  locking  on  some  other 
object  would  not  prevent  get  and  resize  from  executing  concurrently,  resize  could  throw  an 
IndexOutOf BoundsException.  This  would  happen  if  get  incremented  first  (Figure  1.2, 
line  16)  after  resize  used  first  to  determine  the  number  of  elements  to  copy  (Figure  1.4,  line  7) 
but  before  resize  uses  first  as  the  index  of  where  to  start  copying  (Figure  1.4,  line  14).  This 
would  cause  arraycopy  to  throw  an  IndexOutOf  BoundsException. 

Having  access  to  the  code  of  BoundedFlFO  we  can  deduce  from  this  change  that  acquiring  the 
lock  on  the  BoundedFlFO  object  in  clients  is  significant — now  to  do  otherwise  would  compromise 
the  safety  of  the  class.  If  the  programmer  is  unable  to  examine  the  source  code  of  BoundedFlFO 
and  thus  unable  to  learn  that  the  implementation  of  resize  is  synchronized,  the  situation  is  less 
clear:  Is  resize  acquiring  locks  at  all?  Why  do  callers  of  the  resize  method  not  acquire  any 
locks?  Why  must  callers  of  the  other  methods  acquire  a  lock?  Is  the  choice  of  lock  significant?  In 
the  absence  of  any  explicit  expression  of  design  intent,  the  misunderstanding  could  have  been  on  the 
part  of  the  programmer  who  added  resize:  perhaps  it  was  intended  that  clients  have  the  freedom 
to  use  arbitrary  locks — as  long  as  all  clients  use  the  same  lock — in  which  case  resize  should  not 
have  been  made  synchronized. 

1.3.5  Summary 

We  have  identified  the  following  concurrency -related  deign  intent  for  BoundedFlFO: 

•  The  state  of  a  BoundedFlFO  object  must  only  be  accessed  when  the  object  itself  is  locked. 

•  The  state  of  a  BoundedFlFO  object  includes  the  distinct  array  object  referenced  by  buf;  that 
is,  the  FIFO  object  encapsulates  the  array. 

•  We  arc  assured  that  no  other  object  has  a  reference  to  the  array  buf  and  thus  the  state  of  the 
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1  /**  @lock  FIFOLock  is  this  protects  Instance  */ 

2  public  class  BoundedFIFO  { 

3  /**  @unshared 

4  *  ©aggregate  Instance  into  Instance  */ 

5  LoggingEvent []  buf; 

6  int  numElts  =  0,  first  =  0,  next  =  0,  size; 

7 

8  /**  Create  a  new  buffer  of  the  given  capacity.  */ 

9  public  BoundedFIFO (int  size)  {  ...  } 

10 

11  /**  Returns  <code>null</code>  if  empty. 

12  *  @requiresLock  FIFOLock  */ 

13  public  LoggingEvent  get ( )  {  ...  } 

14 

15  /**  If  full,  then  the  event  is  silently  dropped. 

16  *  @requiresLock  FIFOLock  */ 

17  public  void  put (LoggingEvent  o)  {  ...  } 

18 

19  /**  Get  the  capacity  of  the  buffer. 

20  *  @requiresLock  FIFOLock  */ 

21  public  int  getMaxSize ( )  {  ...  } 

22 

23  /**  Get  the  number  of  elements  in  the  buffer. 

24  *  @requiresLock  FIFOLock  */ 

25  public  int  length  ()  {  ...  } 

26 

27  /**  Returns  <code>true</code>  if  the  buffer  was  empty  before  last  put  operation. 

28  *  @requiresLock  FIFOLock  */ 

29  public  boolean  wasEmpty ( )  {  ...  } 

30 

31  /**  Returns  <code>true</code>  if  the  buffer  was  full  before  the  last  get  operation. 

32  *  @requiresLock  FIFOLock  */ 

33  public  boolean  wasFullO  {  ...  } 

34 

35  /**  Is  the  buffer  full? 

36  *  @requiresLock  FIFOLock  */ 

37  public  boolean  isFullO  {  ...  } 

38 

39  /**  Resize  the  buffer  to  a  new  size.  If  the  new  size  is  smaller  than 

40  *  the  old  size  events  might  be  lost.  */ 

41  public  synchronized  void  resize (int  newSize)  {  ...  } 

42  } 


Figure  1.5:  Annotated  class  BoundedFIFO. 


array  is  also  protected  by  locking  the  BoundedFIFO  object  that  refers  to  it. 

•  The  implementation  of  resize  acquires  the  lock  appropriately,  so  clients  do  not  need  to 
acquire  the  lock  before  calling  the  method. 

•  Clients  must  acquire  the  lock  before  calling  the  other  methods  because  they  do  not  acquire 
the  lock  themselves.  Furthermore,  the  clients  must  specifically  acquire  the  lock  that  protects 
the  state  of  the  FIFO:  the  FIFO  object  itself. 

Failure  to  understand  and  respect  this  intent  can  lead  to  errors  during  program  maintenance  and 
evolution.  For  example,  misunderstanding  the  significance  of  the  choice  of  lock  could  lead  to  race 
conditions  between  previously  safe  client  code  and  newly  added  code,  as  described  above. 
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1.4  Evolution  and  Unknown  Intent 

The  above  example  illustrates  some  of  the  model  elements,  as  well  as  some  of  the  problems  of 
recovering  design  intent.  We  now  consider  an  example,  taken  from  Sun’s  JDK,  that  exposes  a  dif¬ 
ferent  set  of  problems  related  to  expectations  about  how  objects  arc  intended  to  be  used  concurrently. 
In  particular,  what  methods  arc  intended/expected  to  interleave  safely  when  invoked  concurrently, 
and  what  methods  arc  intended  to  exclude  each  other.  We  call  this  attribute  the  concurrency  pol¬ 
icy  of  a  class.  An  actual  evolution  scenario  for  the  class  Buf  f  eredlnputStream  of  the  package 
java .  io  provides  an  interesting  example  of  the  dangers  of  evolving  an  inadequately  documented 
“thread-safe”  class.  This  example  shows  another  danger  of  inadequate  documentation  of  design 
intent:  when  descriptions  are  inadequate,  client  programmers  may  develop  their  own  design  con¬ 
ventions  based  on  extant  component  behavior,  regardless  of  whether  the  behavior  is  intended  to  be 
a  fundamental  attribute  of  the  component  or  not.  Specifically,  this  example  shows  how  insufficient 
documentation  of  design  intent  (1)  leads  to  a  race  condition,  (2)  interferes  with  the  evolution  of  the 
class,  and  (3)  encourages  clients  to  develop  their  own  expectations  about  the  concurrent  behavior  of 
the  class. 

The  Java  input-output  model  is  stream  based.  Stream  objects  are  wrapped  by  other  stream  im¬ 
plementations  to  compose  functionality.  A  Buf  f  eredlnputStream  instance  is  a  wrapper  around 
another  input  stream  object  that  provides  buffered  block-reads  instead  of  byte -by-byte  reads  from 
the  underlying  stream.  Documentation  for  the  class,  including  the  documentation  for  its  superclass 
Inputstream,  is  silent  regarding  whether  the  class  is  meant  to  be  thread-safe.  That  is,  is  the  class 
intended  to  be  concurrently  accessed,  and  if  so,  whose  responsibility  is  it,  caller  or  callee,  to  acquire 
the  necessary  lock(s)?  Early  versions  of  the  documentation  combined  with  inspection  of  the  actual 
source  code  suggest  that  some  concurrent  uses  arc  allowable  and  intended  to  be  safe  because  some 
methods  are  synchronized. 

The  read  method  of  Inputstream  is  defined  to  block  until  data  is  available.  This  is  a  problem 
when  using  a  stream  backed  by  a  network  socket:  if  the  network  connection  becomes  hung  then  a 
read  may  block  indefinitely.  Java  programmers  developed  a  convention  to  handle  this,  based  on 
the  inspection  process  just  discussed  and  based  on  observed  behavior  of  stream  implementations. 
The  convention  is  to  invoke  close  on  the  stream  object  from  another  thread  to  abort  and  unblock  a 
read  to  a  “stalled”  socket  stream.  Because  streams  gain  functionality  from  wrappers,  this  conven¬ 
tion  makes  the  general  assumption  that  the  methods  read  and  close  can  always  have  interleaved 
executions,  i.e.,  that  they  do  not  completely  exclude  the  execution  of  the  other.  It  is  also  based  on  the 
assumption  that  closing  a  socket  stream  will  affect  a  blocked  read.  Neither  of  these  assumptions 
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is  grounded  in  behavior  described  in  JDK  documentation;  they  are  based  on  empirically  observed 
implementation-specific  behavior. 

In  JDK  1.2,  the  implementation  of  Buf  f  eredlnputstream  was  modified  to  prevent  a  race 
condition  that  could  occur  when  the  methods  read  and  close  arc  concurrently  invoked  on  the 
same  instance.  The  race  condition  occurs  when  close  sets  the  field  referring  to  the  wrapped  stream 
to  null  after  read  checks  if  the  field  is  null  but  before  read  attempts  to  dereference  the  field.  The 
result  is  a  Null PointerExcept ion  in  the  thread  that  invoked  read.  This  can  only  happen  when 
the  stream  being  closed  is  not  blocked.  To  prevent  the  occurrence  of  this  race  condition,  the  method 
close  was  made  synchronized.  Because  read  was  already  synchronized,  this  prevented  the 
two  methods  from  executing  simultaneously. 

This  change  does  not  appeal-  to  have  been  made  in  response  to  a  publicly  viewable  bug  report. 
A  bug  report  related  to  the  fix,  however,  was  filed:3 

As  of  JDK  1 .2,  BufferedlnputStream’s  close()  method  has  had  the  synchronized  modifier  added 
to  it.  The  Javadoc  does  not  indicate  that  it  is  synchronized,  but  the  source  code  does.  (Actually 
this  is  pretty  scary — why  isn’t  it  the  same?)  [...] 

This  change  in  1.2  breaks  code  that  worked  in  1.1.  One  technique  that  can  be  used  to  “free”  a 
thread  blocked  on  a  read()  is  to  use  a  second  thread  to  close))  the  stream.  This  causes  the  read() 
to  break  out  of  its  blocked  state  and  to  throw  an  IOException.  [...] 

Please  remove  the  synchronized  modifier  from  the  close))  method  of  BufferedlnputStream. 

This  “bug”  in  the  fix  was  itself  fixed  by  unsync hronizing  close  in  the  JDK  1.3  release.  It  remains 
unsynchronized  in  JDK  1.4.  In  this  case,  inadequate  documentation  of  design  intent  (1)  led  to  a 
race  condition  in  BufferedlnputStream;  (2)  caused  client  programmers  to  develop  their  own 
conventions  about  normative  concurrent  usages  of  the  class;  and  (3)  caused  the  safety  of  the  class 
to  be  compromised  for  the  sake  of  these  unanticipated  conventions.  We  note  that  it  is  possible  to  fix 
the  race  condition  in  such  a  way  that  still  allows  close  to  be  used  to  unblock  read. 

This  scenario  occurred  because  of  inadequate  documentation  of  the  behavior  of  Buffered¬ 
lnputStream  objects  when  accessed  concurrently.  The  bug  reporter  points  out  that  the  Javadoc 
documentation  for  the  class  does  not  indicate  that  close  is  synchronized,  and  is  disturbed  that 
the  documentation  does  not  match  the  source  code.  It  was  a  deliberate  decision  on  the  part  of  the 

’Bug  Id  4225348.  “java.io.BufferedlnputStream:  Attempt  to  close  while  reading  causes  deadlock.”  http:// 
developer . j  ava . sun . com/ developer/bugParade/ index . j  shtml. 
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Javadoc  tool  designers,  however,  to  not  include  this  information  in  the  generated  documentation4 

Javadoc  generates  an  API  specification.  [The  keyword  synchronized  does]  not  belong  in 
the  signatures  of  a  specification,  because  [it  is]  implementation-specific.  ...  The  keyword 
synchronized  indicates  thread-safe  behavior  that  should  instead  be  described  in  the  method 
descriptions.  A  thread-safe  method  itself  might  not  use  the  synchronized  keyword  but  might 
call  private  methods  that  are. 

The  authors  of  the  class  did  not  follow  the  above  advice:  Buf  f  eredlnputStream’s  method 
descriptions  do  not  describe  the  concurrent  behavior  of  the  methods.  Without  this  information, 
developers  cannot  understand  how  the  class  is  thread-safe.  That  is,  what  resource-client  conventions 
arc  expected  to  be  followed  to  prevent  the  invariants  of  the  class  from  being  violated.  In  fact,  they 
cannot  know  that  the  class  is  thread-safe  at  all. 


1.5  Locking  Design  and  Representation  Invariants 

Ultimately  locking  design  conventions  are  rooted  in  design  decisions  about  the  maintenance  of 
representation  invariants',  predicates  over  the  state  of  an  object  that  define  when  the  object  is  in  a 
self-consistent  state.  Operations  on  an  object  should  always  move  the  object  from  one  consistent 
state  to  another,  perhaps  temporarily  putting  the  object  into  inconsistent  states.  For  example,  a 
representation  invariant  for  BoundedFlFO  objects  is  that  next  always  has  a  value  between  0  and 
size.  The  put  method  might  temporarily  violate  this  invariant  when  it  increments  next,  but  then 
it  resets  next  to  0  if  it  gets  too  big  (Figure  1.2,  line  25).5  Because  an  operation  should  only  be 
performed  on  an  object  in  a  consistent  state,  a  thread  must  not  be  allowed  to  operate  on  an  object  if 
another  thread  may  have  put  the  object  into  an  inconsistent  state.  Threads  thus  acquire  locks  when 
they  arc  about  to  access  the  state  of  any  object  so  that: 

•  They  do  not  operate  on  an  object  that  is  in  an  inconsistent  state.  An  object  should  always 
be  in  a  consistent  state  when  an  operation  begins,  and  the  operation  should  return  the  object 
to  a  consistent  state.  Locking  also  prevents  another  thread  from  further  modifying  the  state 
of  an  object  while  it  is  already  inconsistent,  which,  by  causing  a  violation  of  some  internal 
precondition  of  the  first  operation,  would  generally  make  it  impossible  to  return  the  object  to 

4“What's  New  in  Javadoc  1.2.:  Provides  More  API  Information  and  Links.”  http://java.sun.com/ 
products/ j  dk/1 . 2/docs/tooldocs/ j  avadoc/whatsnew . html#moreinf o. 

3  This  accounts  for  the  more  specific  invariant  that  next  be  equal  to  the  number  of  put  operations  modulo  the  size  of 
the  queue. 
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a  consistent  state.  The  race  condition  between  read  and  close  described  in  Section  1.4  is 
an  example  of  this. 

•  They  do  not  view  an  object  that  is  temporarily  in  an  inconsistent  state.  This  is  why  even  simple 
“getter”  methods  should  be  synchronized.  For  example,  a  getter  might  reveal  an  intermediate 
value  if  it  could  read  the  value  of  a  field  while  that  field  is  being  used  as  an  accumulator.  Or, 
in  the  above  example,  another  thread  might  view  next  when  it  points  beyond  the  end  of  the 
array,  before  it  is  reset  to  0.  Viewing  an  inconsistent  state  generally  violates  the  expectations 
of  the  client. 

A  race  condition  is  a  manifestation  of  a  failure  to  respect  these  consistency  requirements.  For 
example,  concurrent  puts  cause  an  ArraylndexOutOf  Bounds  exception  when  one  of  the  execu¬ 
tions  observes  the  BoundedFlFO  object  in  the  inconsistent  state  where  next  is  not  less  than  size. 
Concurrent  executions  of  get  and  resize  can  interfere  as  described  above  when  get  alters  first 
in  such  a  way  that  it  falsifies  a  precondition  necessary  for  executing  the  arraycopy  method  on 
line  14:  first  +  lenl  <  size.  The  point  is  the  locking  design  for  a  class  is  informed  by  the 
invariants  that  need  to  be  maintained  for  objects  of  the  class  to  remain  consistent.  If  the  represen¬ 
tation  invariants  were  made  explicit,  then  elements  of  the  necessary  locking  design  would  be  more 
clear  and  the  rationale  of  the  design  would  be  more  self-evident,  particularly  the  points  in  the  code 
where  it  is  necessary  to  acquire  locks.  The  designer  would  still  have  much  freedom  in  choosing 
what  arc  the  particular-  locks  associated  with  invariants  and  in  delegating  caller  vs.  callee  locking 
responsibility. 

Representation  invariants  exist  at  each  level  of  abstraction.  Particularly  with  respect  to  concur¬ 
rency,  a  resource  cannot  always  be  reasoned  about  fully  in  the  absence  of  an  expression  of  the  design 
expectations  of  its  clients.  For  example,  there  is  no  reason  why  two  clients  cannot  simultaneously 
invoke  methods  on  a  shared  BoundedFlFO  object,  as  long  as  the  individual  calls  are  properly  syn¬ 
chronized.  Proper  locking  will  cause  the  methods  to  execute  in  some  serialized  order,  but  that  order 
may  not  preserve  the  higher-level  intent  of  the  clients.  A  client  trying  to  enqueue  an  event  needs  to 
ensure  that  it  has  a  consistent  view  of  the  BoundedFlFO:  if  another  client  were  able  to  invoke  put 
between  the  time  that  the  first  client  verifies  that  the  queue  is  not  full  and  the  time  the  first  client 
invokes  put,  the  second  client  could  cause  the  FIFO  to  be  full  again  and  the  first  client  will  have  its 
event  silently  dropped.  This  is  why  the  getter  and  putter  methods  in  the  FIFO  client  example. 
Figure  1.3,  perform  several  FIFO  actions  within  a  single  synchronized  block.  Understanding 
this,  we  can  also  hypothesize  that  the  reason  clients  of  BoundedFlFO  objects  are  given  the  respon¬ 
sibility  for  acquiring  the  lock  is  that  they  are  going  to  have  to  make  a  series  of  calls  to  the  FIFO  from 
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within  a  single  critical  section,  and  thus  any  locking  performed  by  the  FIFO  implementation  would 
be  redundant  and  misleading.  In  other  words,  safe  implementation  of  a  shared  low-level  resource 
with  respect  to  its  own  internal  invariants  does  not  imply  correct  use  of  that  resource  with  respect 
to  the  invariants  of  a  higher-level  client  resource. 

We  believe  that,  in  general,  it  is  unreasonable  to  expect  working  programmers  to  make  explicit 
the  representation  invariants  of  a  class.  It  is  difficult  (1)  to  identify  what  arc  the  invariants,  (2) 
to  express  the  invariants  with  sufficient  formality,  and  (3)  to  assure  that  implementation  respects 
the  alleged  invariants.  Generally,  a  separate  language  of  assertions  is  necessary  to  express  the  in¬ 
variants,  further  raising  the  barrier  to  entry.  For  example,  the  Houdini  invariant  inference  engine 
[FJL01,  FL01]  was  developed  to  make  the  invariant  documentation  process  less  painful  for  users  of 
ESC/Java  [FLL  '02];  whether  it  satisfies  this  goal  is  still  an  open  question  [NE02],  Assuring  consis¬ 
tency  between  source  code  and  general  representation  invariants,  once  they  arc  expressed,  requires 
theorem  proving.  To  make  this  process  realistic  for  real-world  programs,  ESC/Java  compromises 
both  soundness  and  completeness.  While  in  practice  these  compromises  do  not  detract  from  the 
ability  of  ESC/Java  to  find  potential  programming  errors,  they  make  the  approach  unsuitable  for 
providing  assurance  that  an  implementation  is  consistent  with  programmer  design  intent. 

Our  approach  is  to  describe,  instead,  the  mechanical  attributes  of  the  program,  see  Section  1.2. 
Although  this  approach  is  not  as  expressive  as  assertions  in  a  general-purpose  logic  of  programs, 
it  does  afford  a  means  to  operationalize  several  important  attributes  related  to  code  safety  and  de¬ 
pendability.  For  example,  our  concept  of  concurrency  policy — briefly  introduced  in  Section  1.4, 
and  described  in  detail  in  Chapter  6 — is  intended  to  replace  explicit  representation  invariants  when 
reasoning  about  how  components  interact  in  a  concurrent  setting.  Our  hypothesis  is  that  the  policy 
approach  is  considerably  easier  to  use  and  is  potentially  more  practicable  than  the  aforementioned 
invariant-based  approaches. 


1.6  Towards  A  Generative  Approach  to  Concurrency  Management 

The  primary  focus  of  the  work  described  herein  is  the  assurance  of  concurrency-related  safety 
properties  through  the  use  of  composable  static  analysis  and  design-intent-capturing  program  an¬ 
notations.  This  work,  however,  provides  the  foundations  for  pursuing  a  more  aggressive  research 
goal:  establishing  a  principled  approach  to  the  introduction  and  management  of  concurrency,  al¬ 
lowing  the  trading  off  of  performance  and  concurrency  to  be  explored  without  disturbing  func¬ 
tionality  and  while  keeping  program  complexity  manageable.  Our  goal  is  to  provide  programmers 
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with  techniques  and  tool  support  for  increasing  and  otherwise  altering  concurrency  during  software 
development  and  evolution. 

As  with  our  assurance  techniques,  we  hypothesize  that  our  approach  can  be  of  value  even 
when  only  minimal  functional  specifications  arc  present — indeed,  precisely  because  they  cannot 
be  counted  on  being  present.  Annotations  documenting  design-intent  are  used  to  assist  in  the  safe 
application  by  a  programming  tool  of  semantics-based,  meaning-preserving,  source-level  program 
transformations  that  alter  a  program’s  use  of  concurrency.  A  programmer  requires  discipline  to  ap¬ 
ply  a  library  of  transformations  in  such  a  way  that  the  annotated  design  intent  remains  respected. 
We  have  begun  to  define  a  such  a  discipline,  termed  the  generative  approach,  adherence  to  which 
insures  that  a  concurrent  program  is  always  free  of  the  potential  for  race  conditions,  as  defined  by 
programmer-specified  policy. 

1.6.1  Source-level  Program  Transformation 

Current  concurrent-programming  practice  places  much  responsibility  on  the  programmer.  The  pro¬ 
grammer  is  responsible  for 

•  Identifying  segments  of  shared  state  that  must  be  protected. 

•  Associating  segments  of  code  with  the  regions  of  state  it  accesses. 

•  Placing  the  appropriate  locks  around  code  segments. 

Not  only  must  the  programmer  do  this  correctly  when  the  program  is  initially  developed,  but  the 
programmer  must  also  maintain  the  correctness  of  the  lock  placement  as  the  program  is  evolved.  It 
is  perilous  when  the  programmer  wants  to  modify  the  concurrent  aspects  of  the  program. 

For  example,  increasing  the  granularity  of  the  shared  segments  of  state,  such  as  by  using  regions 
of  objects  rather  than  whole  objects,  would  enable  greater  concurrent  access  to  the  data.  Performing 
this  modification  requires  identifying  all  the  code  segments  associated  with  the  data  regions  be¬ 
ing  partitioned,  and  appropriately  adjusting  the  locking  behavior  of  the  code  segments.  Anecdotal 
evidence  suggests  that  while  this  is  in  principle  a  straightforward  activity,  it  is  error  prone.  The 
programmer  may  miss  some  code  segments  that  need  to  be  changed,  and  incorrectly  change  other 
code  segments,  leaving  shared  data  incorrectly  protected  or  not  protected  at  all.  If  a  code  segment 
makes  use  of  data  that  is  now  resident  in  multiple  data  regions,  and,  therefore,  under  the  protection 
of  multiple  locks,  the  programmer  must  take  care  to  produce  code  that  consistently  acquires  the 
locks  in  the  same  order  or  risk  introducing  potential  for  deadlock. 
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The  difficulty  of  the  tasks  necessary  to  alter  the  concurrent  aspects  of  a  program  can  vary.  Once 
the  locks  needed  to  protect  the  data  accessed  by  a  given  section  of  code  arc  identified,  ensuring  that 
the  locks  arc  consistently  ordered  is  relatively  easy.  Identifying  the  regions  of  data  accessed  by  a 
section  of  code  is  more  difficult,  relying  on  the  programmer’s  decisions  about  allowable  concur¬ 
rency. 

One  of  our  hypotheses — to  be  explored  separately  from  this  dissertation — is  that  programmer- 
initiated,  tool-executed,  meaning-preserving,  source-level  program  transformations  can  assist  the 
programmer  in  “safely”  evolving  a  program.  Here,  in  general,  by  meaning-preserving  and  safely 
we  mean  that  the  transformation  will  not  introduce  race  conditions  or  the  potential  for  deadlock 
into  the  transformed  program.  One  of  our  research  issues  is  to  develop  a  precise  definition  of 
meaning-preserving.  The  safety  of  any  particular  transformation  is  guaranteed  by  its  preconditions 
which  must  be  satisfied  before  it  can  be  performed.  We  restrict  the  term  transformation  to  mean 
a  semantics-based  meaning-preserving  safe  modification  made  to  the  source  code.  This  is  in  con¬ 
tradistinction  with  modifications  to  the  source  code  that  arc  not  safe. 

1.6.2  The  Generative  Approach 

Concurrency-related  source-level  program  transformations  by  themselves  arc  not  enough  to  main¬ 
tain  the  safety  of  a  concurrent  program  as  it  evolves  in  a  practical  engineering  approach.  The  trans¬ 
formations  themselves  must  be  applied  with  respect  to  a  programming  discipline  that  further  insures 
that  the  annotations  used  by  the  transformations  are  correct  and  stay  correct,  and  that  manages  the 
introduction  and  evolution  of  concurrency  policy.  Such  a  discipline  we  call  the  generative  approach. 
Adherence  to  the  generative  approach  insures  that  a  concurrent  program  is  always  free  of  the  poten¬ 
tial  for  deadlock  and  always  free  of  race  conditions,  as  defined  by  a  programmer  specified  policy. 
It  is  based  on  the  observation  that  it  is  easier  to  stay  in  such  a  state  than  to  initially  arrive  at — be 
proven  to  be  in — such  a  state  given  an  arbitrary  concurrent  program.  So  that  the  concurrent  program 
is  known  to  be  initially  safe,  the  generative  approach  prescribes  a  specific  technique  for  increasing 
the  extent  of  concurrency  in  programs:  they  must  be  generated  from  initial  sequential  programs. 
(Prior  work,  e.g.,  [CK79,  SH93,  Her91],  has  taken  this  same  approach;  see  Section  8.8.2.) 

In  our  notional  generative  approach,  a  sequential  class  is  made  concurrent  by  first  turning  it  into 
an  approximation  of  a  monitor  [Hoa74].  This  introduces  an  easily  understood,  simply  implemented 
initial  form  of  parallelism,  together  with  its  related  annotations  and  an  initial  easily  understood 
policy.  Now  that  the  class  is  “concurrent” — and  importantly,  known  to  be  safe — concurrency-related 
transformations  can  be  applied  to  the  program,  e.g.,  to  adjust  the  granularity  of  concurrency  via  a 
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split-lock  transformation,  with  the  assurance  that  the  program  will  remain  safe.  Our  approach  also 
suggests  that  the  introduction  of  additional  threads  of  control  within  a  program  and  inter-thread 
signaling  must  also  result  from  transformation.  Because  concurrent  aspects  of  the  program  must  be 
introduced  and  maintained  via  transformations,  it  is  not  possible  for  all  safely  concurrent  programs 
to  be  produced  using  the  generative  approach.  It  is  a  hypothesis  of  this  research,  however,  that  the 
discipline  provides  sufficient  flexibility  to  produce  programs  that  use  concurrency  in  a  manner  akin 
to  existing  real-world  programs. 

1.6.3  Tool  Support 

Transformations  arc  performed  by  the  tool  on  the  behalf  of  the  programmer  and  their  safety  is 
verified  using  program  analyses.  It  is  our  belief  that  tool  support  is  essential  to  making  our  approach 
practicable.  Scaling  properties  of  the  approach  are  enhanced  through  the  use  of  program  annotations 
that  support  analyses  and  which  provide  mechanical  information  about  the  program.  In  particular, 
the  annotations  and  analyses  intended  for  safety  assurance  arc  reused  in  this  role,  and  our  regions 
and  effects,  described  in  Chapter  4,  have  their  origin  in  our  tool-supported  transformation  research. 

Responsibility  for  design  intent  and  safety  is  partitioned  between  the  programmer  and  the  tool: 
the  tool  strictly  regulates  the  introduction  and  management  of  concurrency-related  annotations  and 
transformations,  while  the  programmer  is  in  complete  control  of  the  original  partitioning  of  a  class 
into  regions  and  other  expressions  of  design  intent. 


1.7  Outline 

The  remainder  of  this  document  is  organized  as  follows.  Chapter  2  provides  additional  background 
on  concurrent  programming  in  general,  and  on  concurrency  in  Java,  in  particular.  Chapter  3  de¬ 
scribes  the  framework,  FluidJava,  we  use  to  provide  a  formal  description  of  our  annotations  and 
analyses.  The  following  chapters  focus  on  specific  kinds  of  design  intent:  Chapter  4  describes  our 
models  of  state,  regions ,  and  an  object-oriented  effects  system  built  on  top  of  it;  Chapter  5  describes 
our  models  for  associating  locks  with  state;  and  Chapter  6  describes  concurrency  policy.  Chapter  7 
describes  our  prototype  analysis  tool  and  preliminary  experience  with  it.  Chapter  8  describes  the 
generative  approach  to  concurrency  management ,  giving  examples  of  several  source  code  trans¬ 
formations  and  exemplifying  how  they  might  be  used  to  evolve  a  concurrent  program.  Finally,  we 
conclude  and  discuss  open  issues  in  Chapter  9. 


Chapter  2 


Concurrency  and  Java 


In  this  chapter,  we  summarize  (1)  the  programming  challenges  raised  by  concurrent  programming, 
(2)  the  advice  given  to  programmers  writing  concurrent  programs,  (3)  the  design  intent  the  pro¬ 
grammer  is  expected  to  manage,  and  (4)  the  concurrency  support  of  the  Java  programming  language 
[AGHOO].  Current  programming  practice  is,  in  general,  still  guided  by  recommendations  that  have 
been  made  since  the  1960s,  e.g.,  [Dij68a,  Dij68b,  Hoa71,  Hav68,  Bir91],  Programmer  adherence  to 
these  recommendations  is  intended  to,  and  generally  does,  insure  that  programs  arc  free  from  race 
conditions  and  deadlock.  Unfortunately,  the  recommendations  place  significant  responsibility  on 
the  programmer  to  apply  the  guidelines  consistently  and,  in  many  cases,  to  maintain  accurate  con¬ 
ceptual  models  apart  from  the  code  itself.  This  reinforces  the  role  of  the  annotation  and  assurance 
techniques  described  in  the  following  chapters  with  respect  to  mitigating  some  of  the  programming 
problems. 

Our  work  is  focused  on  the  Java  programming  language  for  three  reasons.  First,  it  is  used  by 
working  programmers  on  production  products.  This  makes  our  tools  and  techniques  more  directly 
adoptable,  and  also  provides  us  with  a  large  corpus  of  production  source  code  from  which  we 
can  obtain  case  studies  to  evaluate  our  work.  Second,  Java  is  a  typed  language  with  first-class 
encapsulation.  Third,  Java’s  concurrency  features  arc  unremarkable  among  modern  languages,  such 
as  Modula-31  [Nel91],  Ada  95  [TD97],  and  the  Posix  thread  library  [LB98].  In  this  regard,  Java 
is  remarkable  only  because  it  has  forced  concurrent  programming  concerns  into  the  mainstream. 
Java’s  concurrency  support  is  described  in  [GJSB00]  in  terms  of  a  memory  model  that  must  be 

’While  Modula-3  has  never  developed  a  widespread  programmer  base,  it  has  been  influential  within  the  research 
community.  It  is  mentioned  here  because  it  is  populated  with  “simple,  safe,  proven  features”  rather  than  “untried  ideas” 
and  thus  it  is  representative  of  best  practices  in  systems  programming. 


28 


CHAPTER  2.  CONCURRENCY  AND  JAVA 


respected  by  the  Java  Virtual  Machine  (JVM),  known  as  the  Java  Memory  Model  (JMM).  This 
model  is  mostly  irrelevant  for  correctly  written  concurrent  programs,  although  several  exceptions 
arc  noted  below.  Java’s  concurrency  API  centers  around  two  classes,  java .  lang .  Thread  and 
j  ava .  lang .  Ob  j  ect,  and  is  described,  along  with  general  concurrent  programming  techniques,  in 
many  third-party  books,  including  [ Har98.  Hyd99,  LB99,  OW99,  LeaOO,  HolOO]. 

The  primary  message  of  concurrent  programming  guidelines  is  that  efficiency  should  not  be 
emphasized  over  correctness:  “It  is  much  easier  to  start  with  a  correct  program  and  work  on  making 
it  efficient,  than  to  start  with  an  efficient  program  and  work  on  making  it  correct’’  [Bir9 1] .  This 
dissertation  demonstrates  techniques  for  first  assuring  that  a  concurrent  program  is  correct  (with 
respect  to  programmer  design  intent),  and  then  suggests  how  correct  concurrent  programs  can  be 
systematically  evolved  using  program  transformation  techniques  that  preserve  the  program's  cor¬ 
rectness. 


2.1  Shared-Memory  Concurrent  Programming 

The  programming  model  used  by  Java,  and  the  one  we  consider  herein,  is  shared-memory  concur¬ 
rent  programming.  In  this  model,  multiple  threads  of  control — hereafter,  simply  threads — execute 
simultaneously,  accessing  data  in  a  global  memory  space  shared  among  all  present  and  future 
threads.  Any  thread  may  have  a  reference  to  any  object,  and  if  more  than  one  thread  references 
a  particular  object,  that  object  is  shared,  as  arc  any  of  the  objects  reachable  from  that  object.  In  con¬ 
current  programming,  the  problem  is  to  write  a  single  program  that  performs  many  “independent” 
tasks  simultaneously.  While  concurrency  can  be  used  to  increase  the  program  performance,  it  is 
often  the  case  that  the  abstractions  in  a  program  conveniently  map  to  multiple  tasks?  Of  course,  it 
is  rarely  the  case  that  threads  arc  completely  independent,  and  thus  they  typically  do  share  common 
data.  It  is  this  sharing  of  data  that  makes  concurrent  programming  difficult  and  error-prone. 

A  program  begins  with  a  single  thread,  whose  body  is  defined  in  Java  by  the  static  method 
main  (string  []  ).  Thread  lifetimes  arc  dynamic:  a  new  thread  can  be  created  and  started  at 
any  point  by  any  other  thread,  and  a  t  hie  ad  completes  execution  when  its  body  terminates.  A 
program  terminates  when  all  its  threads  have  completed.  In  Java,  additional  threads  arc  created  by 
instantiating  instances  of  the  standard  class  j  ava .  lang .  Thread  or  a  subclass  thereof.  The  body 
of  a  thread  is  defined  in  one  of  two  ways:  (1)  by  extending  Thread  and  reimplementing  the  run 

2This  dissertation  does  not  focus  on  how  to  exploit  concurrency  to  improve  a  program’s  performance,  but  rather  on 
how  to  do  so  safely. 
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method,  or  (2)  by  implementing  the  j  ava .  lang .  Runnable  interface,  which  defines  a  run  method 
only,  and  passing  an  instance  of  the  runnable  to  the  Thread  constructor.  Invocation  of  the  start 
method  causes  a  thread  to  begin  execution;  a  thread  completes  when  its  run  method  returns. 

The  Java  Memory  Model  defines  the  granularity  at  which  memory  accesses  are  atomic.  In 
general,  only  32-bit  variables  arc  guaranteed  to  be  read  or  written  atomically.  The  programmer  must, 
therefore,  treat  shared  long  and  double  variables  as  if  they  were  pairs  of  two  32-bit  variables.  If 
convention  is  followed,  this  is  not  a  significant  issue  because  in  most  correctly  written  concurrent 
programs  all  accesses  to  a  shared  variable — no  matter  its  size  or  structure — should  be  from  within 
a  critical  section. 


2.2  Lock-Based  Concurrency  Management 

Mutual  exclusion  is  a  design  approach  that  limits  access  to  shared  data  to  a  single  t  hie  ad  at  a  time. 
Asynchrony  is  always  resolved  to  a  linear  sequence  of  accesses  to  the  shared  state.  That  is,  im¬ 
plementing  mutual  exclusion  requires  assuring  that  only  one  thread  can  access  an  aggregation  of 
shared  data  at  any  given  time.  Other  threads  wait  until  the  resource  is  available  prior  to  gaining 
access.  This  assures  that  data  invariants  arc  intact  prior  to  any  access  or  mutation  operation.  This 
exclusivity  of  access,  or  “mutual  exclusion,”  is  commonly  achieved  by  using  locks,  also  known  as 
mutexes,  that  allow  threads  to  coordinate  their  actions. 

A  lock  supports  two  operations:  acquire  and  release.  A  t  hie  ad  may  acquire  a  lock  only  if  no 
other  thread  has  already  acquired  it.  If  a  thread  cannot  acquire  a  lock  because  another  thread  is 
holding  it,  then  it  pauses  execution  until  some  point  in  the  future  when  the  lock  is  free.  When  a 
thread  releases  a  lock,  exactly  one  of  the  threads  waiting  to  acquire  the  lock  is  granted  the  lock.  In 
Java,  every  object  may  be  used  as  a  lock,  and  the  acquire  and  release  operations  arc  abstracted  into  a 
single  block-structured  statement:  synchronized  (expr)  {  ...  }.  The  expression  expr  is  evaluated 
first;  it  is  a  compile-time  error  if  it  is  not  a  Java  reference  type,  and  it  is  a  runtime  error  if  it  evaluates 
to  null.  Entrance  into  the  block  implicitly  executes  the  acquire  operation  on  the  lock  object,  and 
exit  from  the  block  implicitly  executes  the  release  operation.  The  keyword  synchronized  may 
also  be  used  as  a  modifier  to  a  method  definition.  This  is  syntactic  sugar  for  enclosing  the  entire 
method  body  within  a  synchronized  block.  For  a  non-static  method,  the  receiver  this  is  used 
as  the  lock.  For  a  static  method  in  class  C,  the  Class  object  for  C  is  used  as  the  lock;  there  cannot 
be  any  ambiguity  in  the  locking  because  static  methods  cannot  be  overridden.  The  expression 
C .  class  evaluates  to  the  Class  object  for  a  class  C. 
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Entering  and  leaving  a  synchronized  block  additionally  has  effects  on  the  management  of 
memory  values  in  the  JMM.  The  practical  outcome  of  these  effects  is  that  the  only  way  to  be  sure 
that  the  most  recently  written  value  of  a  shared  variable  is  read  is  to  (1)  always  read  from  that 
variable  within  a  synchronized  block  and  (2)  always  write  to  that  value  within  a  synchronized 
block.  A  correctly  written  concurrent  program  should  already  be  following  these  guidelines,  so 
this  feature  of  the  JMM  should  not  have  to  be  of  concern  to  most  Java  programmers.  The  JMM 
insures  that  reads  from  fields  declared  to  be  volatile  always  return  the  most  recently  written 
value.  Such  fields  are  useful  in  exceptional  cases,  see  for  example  Section  7.6.5,  but  are  insufficient 
for  maintaining  representation  invariants  spanning  multiple  variables. 

2.2.1  Missing  Intent 

In  Java,  as  in  all  commonly  used  programming  languages,  it  is  the  programmer’s  responsibility  to 
produce  mutual  exclusion.  Every  shared  data  item — global  variable,  field  of  an  object,  etc. — should 
be  associated  with  a  lock,  and  that  lock  should  always  be  used  to  ensure  mutually  exclusive  access 
to  its  associated  data  items.  It  is  up  to  the  programmer  to  choose  the  granularity  of  the  locking:  the 
number  of  locks  to  use  and  how  much,  and  which  state  is  identified  with  any  given  lock.  In  practice, 
this  state  corresponds  to  the  segments  of  state  that  arc  associated  with  particular  data  invariants. 
In  Java,  locks  arc  most  commonly  associated  with  whole  objects,  although  often  the  scope  of  a 
lock  includes  the  state  of  a  referenced  object,  consider  BoundedFlFO  in  Section  1.3.  It  is  also  not 
unusual  to  protect  whole  sets  of  objects  with  a  single  lock,  see  Section  7.6.2.  The  programmer  also 
has  responsibility  to  ensure  that  the  proper  sections  of  code  arc  turned  into  critical  sections  using  the 
appropriate  locks — the  number  and  scope  of  the  critical  sections  depend  on  the  lock  granularity — 
so  that  the  program  invariants  are  preserved.  Critical  sections  arc  only  mutually  exclusive  with 
other  critical  sections  making  use  of  the  same  lock;  that  is,  inconsistent  locking  is  just  as  bad  as  no 
locking.  If  the  programmer  accesses  some  shared  state  while  not  in  a  critical  section,  that  access  can 
be  in  a  race  with  any  of  the  correct  critical  sections  that  access  that  same  state,  even  though  those 
critical  sections  cannot  otherwise  race  with  each  other.  Even  an  access  to  a  single  scalar  variable 
must  be  protected  by  a  mutex  because  it  too  can  be  in  an  inconsistent  state.  Consider  a  variable 
holding  a  sum:  if  that  variable  is  used  to  hold  the  running  value  as  the  sum  is  calculated,  then  the 
variable’s  value  will  be  inconsistent  until  the  calculation  is  complete.  Unfortunately,  it  is  common 
to  see  unsynchronized  “getter”  methods  in  Java  code,  even  in  source  code  from  Sun’s  JDK  [Rou03]. 

In  other  words,  the  programming  language  does  not  make  locking  mandatory  within  concurrent 
programs.  Even  worse,  the  programmer  is  expected  to  maintain  a  separate  model  of  the  associa- 
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tion  between  a  particular  lock  and  the  portions  of  state  it  is  meant  to  protect,  and  then  to  identify 
the  segments  of  code  that  access  that  state.  This  association  and  the  extent  of  the  state  arc  poorly 
documented,  easily  lost,  and  hard  to  recover.  One  of  the  contributions  of  this  dissertation  is  an 
annotation-based,  tool-assisted  process  for  capturing  programmer  design  intent  regarding  the  as¬ 
sociation  between  locks  and  regions  of  state  and  assuring  that  source  code  is  consistent  with  the 
intent. 


2.3  Condition  Variables 

A  thread  may  sometimes  have  to  wait  for  another  thread  to  make  true  a  predicate  over  the  shared 
state  before  proceeding.  The  classic  example  is  a  shared  queue:  an  item  cannot  be  removed  from 
the  queue  if  the  queue  is  empty,  and  an  item  cannot  be  placed  in  the  queue  if  the  queue  is  full. 
Thus  the  dequeue  and  enqueue  operations  must  wait  for  the  queue  to  be  non-empty  and  non-full, 
respectively,  before  they  proceed.  Condition  variables  arc  used  for  this  purpose.  A  thread  invokes 
the  wait  operation  on  a  condition  variable  when  it  wishes  to  wait  for  a  predicate  to  become  true.  The 
waiting  thread  is  removed  from  scheduling.  Another  thread  invokes  the  notify  operation  to  alert  any 
waiters  that  the  condition  has  become  true.  A  condition  variable  must  always  be  associated  with  a 
lock  that  is  used  to  prevent  race  conditions  in  the  condition  variable  itself.  This  lock,  but  not  any 
other  locks  held  by  the  current  thread,  is  released  when  a  thread  waits,  and  is  reacquired  when  the 
wait  operation  returns.  In  Java,  each  object  is  also  a  condition  variable.  This  is  supported  by  the 
wait,  notify,  and  notifyAll  methods  of  Object.  The  object  uses  itself  as  its  lock,  and  thus  it 
is  a  runtime  error  to  invoke  any  of  the  above  methods  without  first  acquiring  the  lock  on  the  object. 

The  guarantees  provided  to  the  awakened  thread  vary  among  implementations  of  condition  vari¬ 
ables  [How76b].  Java  does  not  guarantee  that  the  condition  is  still  true  when  a  thread  resumes,  and 
thus  the  code  template 

synchronized (mutex)  {  ... 

while (! condition)  {  mutex . wait () ;  }  ... 

should  be  used  to  wait  for  the  satisfaction  of  a  condition.  The  template  also  demonstrates  the  fact 
that  a  condition  variable  is  only  implicitly  associated  with  a  predicate  over  the  shared  state.  Again, 
it  is  the  programmer’s  responsibility  to  remember  these  associations.  The  capture  of  design  intent 
regarding  condition  variables  is  beyond  the  scope  of  this  dissertation. 
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2.4  Monitors 

The  disciplined  use  of  locks  and  condition  variables  to  encapsulate  access  to  an  implementation 
of  an  abstract  data  structure  has  come  to  be  known  as  a  monitor  [Dis71,  Hoa74,  BH74,  BH75]. 
A  surprising  degree  of  variation  in  the  behavior  of  monitors  has  developed,  mostly  due  to  how 
condition  variables  are  implemented  [How76a,  How76b,  BFC95].  Java’s  mutual  exclusion  and 
communication  facilities  were  designed  to  make  it  easy  to  write  monitors:  simply  declare  all  the 
methods  of  a  class  to  be  synchronized  and  use  the  receiver  this  as  the  one  and  only  condition 
variable.  If  the  class  has  non-final  non-private  fields,  however,  this  is  not  enough  to  insure 
that  the  class  is  used  in  a  thread-safe  manner:  non-private  fields  can  be  accessed  from  contexts 
other  than  the  body  of  the  class’s  methods,  and  can,  therefore,  be  accessed  without  the  use  of 
synchronization.  Without  adhering  to  a  strict  discipline,  it  is,  therefore,  easy  to  write  a  class  that  may 
not  be  thread-safe.  This  has  caused  the  language  to  be  criticized  [BH99b];  the  proposed  solution, 
however,  requires  the  programmer  to  use  only  highly  restrictive  forms  of  monitors,  eliminating  the 
potential  to  implement  classes  that  support  high  degree  of  concurrency,  and  also  severely  limiting 
the  usefulness  of  inheritance  in  a  concurrent  setting.  One  of  the  goals  of  this  work  is  to  provide  a 
framework  for  managing  the  assurance  of  state  outside  such  strict  encapsulations. 


2.5  Additional  Risks  of  Concurrency 

The  use  of  mutual  exclusion  introduces  the  possibility  of  deadlock.  Because  threads  using  locks 
must  temporarily  pause  execution  while  trying  to  acquire  a  lock  that  is  held  by  another  thread,  it 
is  possible  for  a  set  of  threads  to  become  permanently  stalled  if  they  have  a  cyclic  dependency  on 
each  other.  Thus,  the  technique  for  avoiding  one  kind  of  error — race  conditions — has  the  potential 
for  introducing  another  kind  of  error.  Programmers  arc  recommended  to  assign  a  partial  order  to 
the  locks  used  by  a  program;  locks  should  always  be  acquired  in  an  order  that  respects  that  partial 
order.  Similarly,  the  “components”  of  a  program  should  be  organized  in  a  hierarchical  manner 
[BH74].  It  should  not  be  the  case  that  a  process  placed  in  wait  by  a  lower-level  component  can  only 
be  awakened  by  an  action  of  a  higher-level  component.  In  general,  this  can  be  avoided  by  holding 
no  mutex  when  “calling  down”  through  the  levels  of  abstraction,  but  it  is  often  non-trivial  to  arrange 
the  code  so  that  this  is  the  case.  This  avoids  the  nested  monitor  problem  [Lis77]. 

Techniques  for  capturing  design  intent  that  may  be  used  to  assure  freedom  of  deadlock  arc  out 
of  the  scope  of  this  dissertation,  although  the  issue  is  briefly  visited  in  Section  9.2.1. 


Chapter  3 


Recording  Design  Intent 


Our  approach  to  expressing  models  of  design  intent  for  concurrency  and  related  design  issues  is  to 
annotate  Java  program  source  code.  Annotations  are  embedded  within  Java  comments.  This  avoids 
any  need  to  alter  existing  language  tools  such  as  compilers  and  IDEs.  This  is  common  practice  and 
is  precedented  by  such  tools  as  LCLint  [EGHT94]  (now  Splint  [EL02]),  Extended  Static  Checking 
(ESC)  [DLNS98,  FLL  02],  and  Anna  [Luc90].  The  Java  community  already  accepts  the  use  of 
formalized  comments  via  the  Javadoc  documentation  generation  standard.  In  fact,  the  majority  of 
our  design-intent-capturing  annotations  take  the  form  of  Javadoc  tags.  This  has  several  advantages: 

•  Java  programmers  arc  already  used  to  encountering  and  producing  Javadoc  comments. 

•  The  Javadoc  documentation  engine  is  extensible  and  can  be  made  to  incorporate  design  ra¬ 
tionale  based  on  our  annotations  into  the  generated  document.  (We  have  not  yet  done  this  for 
our  annotations.) 

•  Libraries  exist  for  manipulating  Javadoc  within  source  code,  simplifying  our  implementation 
effort. 


3.1  Analysis  and  Assurance  of  Design  Intent 

Static  analysis  is  used  to  assure  that  source  code  is  consistent  with  annotated  design  intent.  When 
there  is  an  inconsistency,  then  either  the  code,  the  annotated  design  intent,  or  both  may  be  wrong. 
In  particular,  design  intent  may  be  incorrectly  captured  or  misunderstood.  In  general,  the  process 
for  assuring  consistency  between  annotated  design  intent  and  implementation  is  iterative. 

Static  analyses  must  necessarily  be  grounded  in  the  semantics  of  the  target  language,  Java, 
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if  assurances  about  program  behavior  arc  be  meaningful.  There  is  no  formal  semantics  for  the 
complete  Java  language.  It  is  standard  practice  to  use  scaled-down  versions  of  the  Java  language 
when  describing  analyses  to  avoid  having  to  address  features  of  the  language  that  arc  irrelevant  to 
the  properties  of  interest.  We  thus  introduce  our  own  scaled-down  Java  language,  FluidJava,  over 
which  we  formalize  our  analyses.  Our  analyses  primarily  resemble  type  systems,  and  are  presented 
as  such  in  our  mini  language.  We  say  more  about  the  soundness  of  particular  analyses  as  they  arc 
presented  in  later  chapters. 

In  the  following  chapters  we  introduce  annotations  for  recording  concurrency-related  design 
intent,  extend  our  mini  Java  language  to  support  those  annotations,  and  describe  analyses  for  pro¬ 
viding  assurance  based  on  those  annotations.  For  clarity,  source  code  examples  arc  always  in  full 
Java  with  annotations;  use  of  FluidJava  language  is  generally  reserved  for  formal  presentations  of 
analysis. 


3.2  The  FluidJava  Language 

We  use  a  mini-language  called  FluidJava1  based  on  the  ClassicJava  and  ConcurrentJava  lan¬ 
guages  of  [FKF98]  and  [FFOO,  BR01,  BLR02],  respectively.  ClassicJava  was  originally  used  as 
the  base  language  for  studying  models  of  inheritance  in  Java.  Features  it  is  missing  include  scalar 
types,  mutable  local  variables,  and  concurrency.  As  a  small  Java-like  language,  however,  it  has  also 
been  used  by  others,  e.g.,  [FFOO,  BR01,  Yat99],  as  the  basis  for  presenting  analyses  for  Java  pro¬ 
grams.  In  particular,  [FFOO,  BR01,  BLR02]  derive  a  mini-language  supporting  concurrency  from 
ClassicJava  that  they  call  ConcurrentJava. 

FluidJava  is  basically  ClassicJava  with  the  concurrency  features,  final  variables,  mutable 
local  variables,  and  int  and  boolean  scalar  types  of  ConcurrentJava,  but  with  interfaces  re¬ 
moved  from  the  language.  Additional  differences  are  noted  as  relevant.  Mutable  local  variables, 
final  variables,  and  scalar  types  arc  interesting  for  effects  analysis. 

3.2.1  The  Language 

The  grammar  for  FluidJava  is  shown  in  Figure  3.1.  A  program  is  a  sequence  of  class  definitions 
followed  by  an  initial  expression  that  replaces  the  standard  Java  public  static  void  main 
method.  The  class  Ob  j  ect  is  predefined  and  is  the  root  of  the  class  hierarchy.  Programmer-defined 

’This  research  was  performed  as  part  of  the  Fluid  Project,  hence  the  name. 
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P 

defn 

field 

meth 

body 

arg 

mod_t 

t 

c 

e 


defn*  e 

class  cn  extends  c  {field*  meth*} 
mod_t  fd  =  e 
t  mn(arg*)  {body} 
e  |  abstract 
mod_t  x 

[fina|]opt  1 

c  |  int  j  boolean 
cn  |  Object 

null  |  new  c\x\x=e  \  e.fd  \  e.fd  =  e  \  e.mn{e*)  |  super.  mn{e*) 

ei;e2  |  let  mod_t  x  =  e  in  { e}  |  if (e)  {e}  else  { e}  |  synchronized(e)  {e}  |  fork  { e} 


Identifiers  are  drawn  from  the  following  distinct  name  spaces: 

cn  £  class  names  fd  £  field  names  mn  £  method  names  x  £  variable  names 

Figure  3.1:  The  grammar  for  FluidJava. 


classes  must  extend  exactly  one  class;  this  guarantees  that  all  classes  are  comparable  with  Object. 
Variable  and  field  declarations  always  include  initialization  expressions  and  may  optionally  be  de¬ 
clared  as  final.  Additional  points  to  note  about  the  language  are: 

•  The  receiver  this  is  not  treated  as  a  distinguished  expression,  but  is  instead  a  final  local  vari¬ 
able  added  to  the  environment  when  type  checking  method  bodies. 

•  Fields  and  methods  do  not  have  visibility  modifiers:  they  are  all  effectively  public. 

•  The  name  spaces  for  methods,  fields,  classes,  and  local  variables  are  distinct  and  disjoint. 

•  Methods  are  declared  to  be  abstract  via  the  method  body  {abstract}. 

•  Classes  do  not  have  constructors.  Instead  all  fields  have  explicit  initializers. 

•  While  ClassicJava  allows  fields  to  be  shadowed,  we  have  chosen  to  remove  this  feature  in 
order  to  simplify  reasoning  about  fields,  and  in  later  chapters,  regions. 

•  Unlike  the  full  Java  language  in  which  threads  arc  special  objects,  in  FluidJava,  threads  arc 
created  using  an  explicit  fork  expression  that  executes  its  body  in  a  newly  created  thread. 
The  result  of  this  expression  is  uninteresting  and  is  typed  as  an  int.  Traditional  Java  Thread 
objects  can  be  translated  straightforwardly;  Figure  3.2  shows  one  possible  translation. 

3.2.2  Language  Predicates 

Several  predicates  and  relations  arc  used  to  reason  over  a  program  P.  These  arc  based  on  the  pred¬ 
icates  from  [FKF98]  and  arc  shown  in  Figure  3.3.  These  predicates  are  used  to  insure  the  program 
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Java 


FluidJava 


public  class  MyThread  extends  Thread  { 
private  int  x  =  0; 


class  MyThread  extends  Object  { 
int  x  =  0 


public  void  run ( )  {  ...  } 

public  static  void 
main(String  args [] )  { 

MyThread  t  =  new  MyThread ( ) ; 
t . start ( ) ; 

} 

} 


int  run ( )  {  ...  } 

} 


let  MyThread  t  =  new  MyThread 
in  {  fork  {  t . run ( )  }  } 


Figure  3.2:  One  possible  translation  of  a  Java  t  hie  ad  class  into  FluidJava. 


ClassOnce(P)  =  Vc,  d  :  class  c  •  •  •  class  d  ■  ■  ■  is  in  P  =>  c  ^  d 

FieldsOnce(P)  =  dfd,fd '  :  class  t  fd  ■  ■  ■  t'  fd'  ■  ■  ■}  is  in  P  =>•  fd  7^  fd' 

MethodsOnce(P)  = 

Vmn,  mn'  :  class  mn(-  •  •){•  mn\-  ■  •){■  ••}•••}  is  in  P  =r-  mn  ^  mn' 

c  -<c  d  class  c  extends  d  ••■{■■■}  is  in  P 

(c./d,  mod_t)%zc c  class  <:•••{•••  mod_t  fd  ■  ■  ■}  is  in  P 

(mn,  ti . . .  tn  — >  t,  (xi . . .  Xn),  e)€Ecc  class  c  •••{•••  t  mn([final]ODt  ti  xi  . . .  [final]ODt  t„  Xn){e}  ■  ■  •}  is  in  P 

<c  =  the  transitive,  reflexive  closure  of 

NoShadowing(P)  = 

(c.fd,  mod_t)^cc  =>  (fid,  mod_t'  :  c  ^  d  A  c  <c  d  A  (d .fd,  mod_t')%d d) 

CompleteClasses(P)  =  rng(^:c)  C  dom(-<c)  U  {Object} 

WFClasses(P)  =  <c  is  antisymmetric 

ClassMethodsOK(P)  = 

Vc,  d,  e,  d,  mn,  T,  T' ,  V,  V'  :  ((mn,  T,  V,  e)<£cc  A  (mn,  T\  V’ ,  d)<£cd)  =>  (T  =  T1  V  c  d) 

(d .fd,  mod_t)  ecctt  (d .fd,  mod_t)^c d  A  c  <c  d 

(mn,  T,  V ,  e)  £c  c 

(mn,  T,  V,  e)<£cd  A  d  =  min{c"|c  <c  c"  A  3d,  V'  :  (mn,  T,  V',  d)(£cd'} 

NoAbstractMethods(P,  c)  =  Vmn,  T,  V,  e  :  (mn,  T,  V,  e)  £c  c  =*•  e  ^  abstract 

Figure  3.3:  Predicates  and  relations  in  the  model  of  FluidJava.  Based  on  Figure  4  of  [FKF98]. 
The  relation  “is  in”  relates  arbitrary  symbol  sequences.  Centered  ellipses  “■  •  •”  arc  an  arbitrary 
sequence  of  symbols  with  balanced  braces  and  parentheses,  while  “. . .”  indicate  a  repeated  pattern 
or  continued  sequence.  The  meta-variable  T  abbreviates  method  signatures  \  . . .  tn .  — *  t,  and  V  is 
used  for  variable  lists  (x\  . . .  xn ) .  Relations  arc  implicitly  parameterized  by  the  program  P. 
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Judgment 

Meaning 

\-P:t 

P  F  defn 

P  F  mod_t 

P  F  field 

P,  c  F  meth 
P;  E  F  e  :  t 

Program  P  yields  type  t 
defn  is  a  well  formed  definition 

Type  mod_t.  exists 

field  is  a  well  formed  field 

meth  is  a  well  formed  method  in  type  c 

expression  e  has  type  t 

Figure  3.4:  Typing  judgments  for  FluidJava. 


is  well  formed.  ClassOnce(P)  insures  that  class  names  arc  declared  only  once.  Within  each 
class  definition,  FieldsOnce(P)  and  MethodsOnce(P)  insure  that  field  and  method  names  are 
unique.  Predicate  NoShadowing(P)  is  satisfied  when  a  class  definition  does  not  shadow  any 
fields  declared  in  its  ancestors. 

CompleteClasses(P)  checks  that  classes  that  are  extended  are  defined;  WFClasses(P) 
checks  that  the  class  hierarchy  is  an  order  (no  loops).  ClassMethodsOK(P)  insures  that  method 
overriding  preserves  type.  Finally,  NoAbstractMethods(P,  mn)  is  used  as  an  antecedent  to  the 
new  evaluation  rule  to  prevent  the  instantiation  of  classes  with  abstract  methods. 

The  transitive-reflexive  closure  of  the  immediate  subclass  relation  -T  is  used  to  define  the 
subclass  relation:  <c.  The  relation  (Ec  records  what  fields  and  methods  arc  declared  in  a  particular 
class,  while  the  relation  Gc  records  what  fields  and  methods  are  contained  in  a  class. 

3.2.3  Typing  Rules 

Typing  environments  keep  track  of  local  named  state:  they  have  the  form 

E  ::=  0  |  P,  mod_t  x 

The  predicate  x  G  E  tests  whether  variable  x  is  defined  in  an  environment  E: 

x  €  E  E  =  Ei,  mod_t  x,  E2 

Figure  3.4  shows  the  forms  of  the  typing  judgments  for  FluidJava.  The  basic  typing  rules  arc 
shown  in  Figure  3.5.  These  rules  arc  based  on  those  of  [FKF98]  without  the  type  elaboration,  but 
arc  presented  in  a  form  more  similar  to  that  of  [FFOO].  Here  we  briefly  describe  the  typing  rules. 
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Prog 

ClassOnce(P)  FieldsOnce(P)  MethodsOnce(P)  NoShadowing(P)  CompleteClasses(P) 
WFClasses(P)  ClassMethodsOK(P)  P  =  defn 1  . . .  defnn  e  P  b  defn i  P;  0  b  e  :  t 


b  P  :  t 


Class 

P  b  fieldi  P ,  on  b  methi 


Field 

Pbi  P;0  b  e  :  t 


P  b  class  cn  ■  ■  ■  {fields  . . .  field  •  methi  ■  ■  ■  meth j,} 


p  h  [fina|]oPt  tfd=  e 


Method  FinalType 

P  b  4  P  b  mod_ti  P;  final  c  this,  mod_t\  Xi, . . .  ,  mod_tn  xn  b  e  :  t  P  b  t  INT 

P,  c  b  t  mn(mod_ti  xi  . . .  mod_tn  xn)  {e}  P  b  final  f  P  b  int 


Bool 


Obj  Sub  Null 

t  e  dom(Ac)  U  {Object}  P;  E  h  e  :  c'  c'  <c  c  P  b  c 


P  b  boolean 


P  b  t 


P;E  b  e  :  c 


P;Bb  null  :  c 


New  Var  Assign 

P  b  c  NoAbstractMethods(P,  c)  F  =  Fj  ,  [final]opt  tx,  Eq  P;  F  b  e  :  t  F  =  Fj ,  £  a:,  Fg 

P;  F  b  new  c:c  P;  E  h  x  :  t  P;  F  b  x  =  e  :  t 


Get 

P;  F  b  e  :  c  (c1  .fd,  [final]opt  t)  Gc  c 


P;  F  b  e.fd  :  t 


Set 

P;  F  b  e  :  c  ( c'.fd,t)£cc  P;  F  b  e'  :  i 


P;  F  b  e./d  =  e!  :  £ 


If 

P;  F  b  ej  :  boolean  P;  F  b  eg  :  t  P;F  h  ej  :  f 


P;  F  b  if (ej )  {eg}  else  {eg}  :  t 


Let  Sync 

mod_t  =  [final]opt  t  x  £  E  P;  F  b  ej  :  t  P;  F,  mod_t  x  b  eg  :  F  P;  F  b  ej  :  c  P;  F  b  eg  :  f 

P;  F  b  let  mod_t  x  =  ej  in  {eg}  :  t'  P;  F  b  synchronized^ )  {eg}  :  t 


Fork  Invoke 

P;Ehe:l  P;  F  b  e  :  c  P;  F  b  e*  :  £j  (mn,  ti  . . .  £n  — >  t,  V,  e/,)  Sc  c 

P;  F  b  fork  {e}  :  int  P;  F  b  e.mn(e i  . . .  en)  :  £ 


Super 

P;  F  b  this  :  c'  c'  Ac  c  (mn,  £i  . . .  tn  — ►  t,  V,  ej, }  Sc  c  e;,  yf  abstract  P;  F  b  ei  :  £i 


P;  F  b  super. nm(ei  . . .  en)  :  £ 


SEQ 

P;  F  b  ej  :  fj  P;  F  b  eg  :  £g 
P;  F  b  ej ;  eg  :  tg 


Abstract 
P  b  t 


P;  F  b  abstract  :  t 


Figure  3.5:  Typing  rules  for  FluidJava. 
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A  program  evaluates  to  type  t  if  all  its  class  definitions  arc  well  formed,  the  previously  described 
predicates  arc  satisfied,  and  the  body  of  the  program  evaluates  to  type  t.  A  class  definition  is  well 
formed  if  all  the  field  and  method  declarations  it  contains  arc  well  formed.  Field  and  method 
declarations  arc  checked  in  an  environment  in  which  the  receiver  is  declared  to  be  final,  preventing 
object  identity  from  being  changed. 

A  field  is  well  formed  if  its  declared  type  exists  and  the  type  of  its  initialization  expression  is 
compatible  with  the  declared  type  of  the  field.  Proving  this  may  require  intervening  usages  of  the 
subtyping  rule  Sub.  A  field’s  initializer  is  checked  in  an  environment  where  the  receiver  this  is 
not  defined.  This  prevents  initialization  expressions  from  referring  to  fields  that  have  not  yet  been 
initialized.  It  also  prevents  them  from  invoking  methods  on  the  object,  which  is  problematic  because 
methods  may  also  refer  to  fields  that  arc  not  yet  initialized.  A  method  is  well  formed  if  its  return 
type  and  the  types  of  its  arguments  exist  and  the  body  of  the  method  can  be  proven  to  have  the 
declared  return  type.  The  Abstract  typing  rule  allows  abstract  method  bodies  to  have  any  type  so 
that  abstract  methods  arc  well  formed. 

A  type  exists  if  it  is  the  primitive  type  int  or  boolean,  the  built  in  reference  type  Object,  or  the 
name  of  a  class  declared  in  the  program. 

The  subtyping  rule  Sub  allows  the  type  of  an  expression  to  move  up  the  type  hierarchy.  A  null 
expression  can  be  typed  to  any  existing  class  type.  A  new  c  expression  has  type  c  if  c  is  an  existing 
non-abstract  class  type;  the  syntactic  restriction  of  c  to  the  class  name  space  prevents  instantiation 
of  non-class  types. 

The  type  read  from  a  local  variable  is  according  to  the  typing  environment.  The  type  of  assigning 
to  a  non-final  local  variable  is  also  according  to  the  typing  environment,  but  only  if  the  rvalue 
expression  has  the  appropriate  type;  a  final  variable  cannot  be  assigned  to. 

The  type  read  from  an  object  field  is  according  to  the  declared  type  of  the  field  in  the  object’s 
type.  Assignment  to  a  non-final  field  has  the  type  of  the  field  if  the  rvalue  expression  is  of  the 
appropriate  type. 

The  typing  of  the  if,  let,  synchronized,  fork,  and  sequencing  expressions  is  straightforward, 
although  the  following  points  arc  worth  noting:  the  let  expression  allows  read-only  variables  to  be 
declared  and  prevents  the  shadowing  of  local  variable  names,  ej  must  type  to  a  reference  type  for 
the  synchronized  expression,  and  the  resulting  value  of  fork  expression  is  uninteresting  and  thrown 
away. 

A  method  invocation  has  the  return  type  of  the  invoked  method  if  the  receiver  expression  has  a 
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meth  ::=  t  mnibi(arg*)  {body} 
arg  ::=  mod_t  [x]ibi 
e  ::=  . . .  |  [e\m 

Labels  arc  drawn  from  a  new  name  space,  distinct  from  the  others:  Ibl  e  expression  labels 
Figure  3.6:  FluidJava  grammar  with  labeled  expressions. 


Prog 

ClassOnce(P) 

FieldsOnce(P)  MethodsOnce(P)  NoShadowing(P)  CompleteClasses(P)  WFClasses(P) 
ClassMethodsOK(P)  UniqueLabels(P)  P  =  defn j  . .  .  defnn  e  Ph  defni  P;0  h-  e  :  f 

hP:( 


Method 


Phi  Ph  mod_ti 

E  =  final  c  this,  mod_tb  si, ... ,  mod_tn  xn  P;  E  h  e  :  t  fip  3  {(Ibl,  E),  (Ibli ,  E), . . . ,  ( lbln ,  E )} 
P,ch  t  mnibi(mod_t1  [si]iHl  . . .  mod_tn  [xn]ibln)  {e} 


Label 

P;E\-e:t  SP  D  {(Ibl,  E)} 


P,  E  h  [e\ibi  ■  t 


Figure  3.7:  Type  rules  for  labeled  expressions. 


reference  type  and  the  arguments  evaluate  to  the  appropriate  types.  The  class  member  relation 
takes  method  overriding  into  account.  The  superclass  invocation  expression  types  similarly  except 
that  it  starts  the  method  lookup  in  the  super  class  and  must  insure  that  the  found  declaration  is 
non-abstract. 


3.3  Labeling  Expressions 

We  wish  to  be  able  to  identify  where  in  a  program  an  expression  comes  from.  This  is  used  to  make 
the  “context”  of  an  expression  implicit,  and  is  also  fundamental  to  our  alias  resolution  scheme.  We 
thus  modify  the  grammar  of  FluidJava  so  that  expressions  may  be  uniquely  labeled.  The  labels 
differentiate  otherwise  lexically  identical  expressions  based  on  their  position  in  the  program.  We 
also  label  the  formal  parameters  of  method  declarations;  the  method  declaration  itself  is  labeled  to 
provide  a  label  for  the  implicit  parameter  this.  In  our  implementation,  we  use  the  position  of  an  ex¬ 
pression  or  declaration  in  the  Java  parse  tree  as  the  label.  Labels  are  added  to  the  grammar  by  adding 
a  new  labeled  expression,  and  by  modifying  the  meth  and  arg  productions.  This  makes  labeled  ex¬ 
pressions  optional,  but  aliasing  resolution  and  effects  comparison  as  described  in  Section  4. 1 1  will 
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not  work  in  general  unless  all  expressions  arc  labeled.  The  modifications  to  the  grammar  arc  shown 
in  Figure  3.6. 

For  labels  to  be  useful,  each  expression  must  be  uniquely  labeled.  UniqueLabels(P)  checks 
this  property,  specifically  that  every  label  in  a  program  P  is  unique,  and  is  added  to  the  antecedents 
of  the  PROG  rule;  see  Figure  3.7.  The  definition  of  the  predicate  is  obvious,  but  tedious,  and  so  is 
omitted.  The  definition  of  (Ec  for  methods  is  updated  to  ignore  the  labels  on  the  formal  parameters 
(see,  for  example,  the  definition  in  Figure  4.7).  Labels  allow  us  to  reconstruct  the  environment  of 
an  expression  based  on  its  label.  For  a  well  formed  program  P,  i.e.,  a  program  with  unique  labels, 
we  define  the  function  £p  that  maps  a  label  to  an  environment.  This  function  is  defined  using  a 
set  constraint  as  an  antecedent  to  the  new  Label  rule,  which  otherwise  propagates  the  type  of 
the  underlying  expression;  we  also  modify  Method  to  assign  an  environment  to  the  labels  of  the 
formal  parameters. 

Labels  do  not  affect  the  equality  of  variable  names  when  looking  up  variables  in  the  environ¬ 
ment.  In  general,  we  elide  labels  when  appropriate. 


3.4  Binding  Context  Analysis 

We  need  to  be  able  to  track  the  mutable  state  references  that  could  occur  in  local  variables.  We  use 
what  we  call  “Binding  Context  Analysis”  to  compute  a  relation  between  local  variables  and  such 
references  that  each  variable  may  be  equal  to.  The  relation  also  permits  a  local  to  be  paired  with 
the  initial  value  of  a  formal  method  parameter.  This  analysis  is  similar  to  def-use  analysis  for  local 
variables,  except  that  it  traces  through  local  variable  assignments  to  determine  the  ultimate  source 
of  the  value  that  reaches  a  particular  variable  use.  The  set  of  variable  bindings  is  the  set  of  program 
expressions.  The  binding  relations  arc  drawn  from  the  set  VB  for  “variable  bindings:” 

Bindings  =  e 

■yrg  _  2 (this  U  variable  names)  X  Bindings 

The  function  B  e  V  gives  the  set  of  possible  bindings  for  a  labeled  expression  e  based  on  the  binding 
relation  V. 

B  :  e  — >  VB  — >  2Bindinss 

f  {b  |  (x,b)  G  V}  (e  =  [x]m) 

BeV  =  l  {}  (e  =  [null]®,) 

I  { e}  (Otherwise) 
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meth  ::=  t0  mnm(mod_ti  . . .  mod_tn  [xn\ibin){[e}m} 

Vlbl  =  {(th'S’  [thisUz),  (Xl,  [Xi  }lbh),  (. Xn ,  [XnhwJ} 

e  ::=  [null]iW 

vi  =  vs 

e  ::=  [new  c]w 

^Z&Z  =  ^Z&Z 

e  ::=  [x]m 

vi  =  vs 

e  ::=  [x  =  [e'] 

Vw  vm  =  Viw  ((Viti'V)  U  {(*,  6)  1  6  G  B  [e']iw  V+,}) 

^Z6Z  =  ^Z6Z>  ^Z&Z' 

e  ::=  [[eo]i6i0-mra([el]tHj  •  •  •  [en]zM„)hw 

y-  y-  y+  —  y-  y+  y+ 

e  ::=  [su per. mn( [ei] ibil  •••  [en]«,z„)W 

y-  y-  y+  —  y-  y+  y+ 

e  '■'■=  [[el]z6Zi  i  [^2] ZZ>ZS ] Z6Z 

y-  y~  y+  —  y-  y+  y+ 

^ZfoZi  ’  ^ZfoZ-^  ’  ^ZfoZ  —  v  Ibl >  vZ6Zi  ’  y&Z? 

e  ::=  [let  [final]opt  i  x  =  [ei]*Wj  in  { [e2] zb/s }] Z6Z 

VS,.  VS,,  v+  =  VS,  ((V+»  U  {(x,6)  b€B  [ei]iMl  V+j)  ,  V+, 

e  ::=  [if([ei]^ )  {{e2]ibi2}  else  {[ez]ius}}ibi 

^Z6Zi>  Vlbh,  Vlbl  =  Vlbl,  v£h,  v£h,  (v£h  UVjjjJ 

e  ::=  [synchronized([ei]jWj )  {[e2\iu2}\ibl 

y-  y~  y+  —  y-  y+  y+ 

vlbl i>  ^ZfoZc.  ’  ^Z6Z  —  v  Ibl >  vZ6Zi  >  v Ibb 

e  [fork  {[e']w, 

VS„  v,J  =  vs,  (VS  U  V+.) 

Figure  3.8:  Syntax-based  system  of  equations  defining  the  variable  bindings  before  and  after  the 
execution  of  an  expression.  We  let  V\x  =  V  —  {(x,  b)  \  b  e  Bindings}. 
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For  each  labeled  expression  [e\u,i,  we  define  two  sets  of  variable  bindings  VB  and  V,f,  as  the 
least  fixed  point  solution  to  the  set  of  equations  defined  with  regal'd  to  the  syntax  of  each  method 
shown  in  Figure  3.8.  We  will  primarily  use  binding  context  analysis  to  get  the  values  that  may  be 
bound  to  a  local  variable.  We  thus  let  B  [x\iu  be  shorthand  for  B  [x\ibi  Vlhl . 


Chapter  4 


An  Object-Oriented  Effects  System 


To  identify  the  program  state  that  is  intended  to  be  shared,  the  programmer  must  be  able  to  name 
sections  of  program  state  in  general.  This  is  challenging  because  (1)  not  all  state  is  explicitly  named 
by  program  variables,  and  (2)  inappropriate  use  of  private  or  local  program  names  can  violate  prin¬ 
ciples  of  encapsulation  and  frustrate  program  evolution.  Our  approach  to  identifying  state  extends 
our  object-oriented  effects  system,  originally  described  in  [CBS98,  GB99,  GS02],  Effects  systems, 
originally  studied  by  Gifford  and  Lucassen  [GL86],  answer  the  question  what  state  is  affected.  This 
question  must  be  answered,  for  example,  to  ensure  all  accesses  to  shared  state  are  identified  so 
that  locking  policies  will  be  complied  with.  An  effects  system  is  an  adjunct  to  a  type  system  and 
includes  the  ability  to  infer  the  effects  of  a  computation,  to  declare  the  permitted  effects  of  a  com¬ 
putation,  and  to  check  that  the  inferred  effects  arc  within  the  set  of  permitted  effects.  The  effects  of 
a  computation  include,  for  example,  the  reading  and  writing  of  mutable  state. 

Our  object-oriented  effects  system  uses  program  annotations  to  identify  state  hierarchically,  to 
declare  the  upper  bound  of  the  effects  of  methods,  and  to  aggregate  the  state  of  collaborations  of 
objects.  These  annotations  capture  design  intent  with  respect  to  how  the  programmer  thinks  about 
the  state  of  an  object,  or  set  of  objects,  and  the  operations  of  those  objects.  Composable  analyses 
determine  effects  and  check  that  the  effects  of  method  implementations  arc  consistent  with  their 
declared  effects.  Declaring  the  permitted  effects  of  a  method  necessarily  constrains  the  implemen¬ 
tation  of  a  method  and  any  method  that  overrides  it.  Such  effects  declarations  pose  two  abstraction 
problems:  (1)  we  do  not  want  effect  declarations  to  reveal  specific  implementation  details  and  (2) 
we  want  overriding  implementations  to  be  able  to  access,  within  reason,  newly  declared  state  that 
is  necessarily  unavailable  to  the  original  declaration.  Thus,  one  of  the  requirements  for  a  useful 
effects  system  for  an  object-oriented  language  such  as  Java  is  that  it  preserve  the  ability  to  hide 
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the  names  of  private  fields:  it  should  use  abstract  names  that  map  to  multiple  mutable  locations. 
We  use  named  regions  in  an  object:  the  regions  of  an  object  provide  a  hierarchical  covering  of  the 
notional  state  of  the  object.  The  definition  of  the  region  hierarchy  thus  answers  the  question  what  is 
the  program  state.  Programmer-declared  effects  in  annotations  and  analysis-reported  effects  are  in 
terms  of  regions,  meeting  our  abstraction  requirement. 

In  brief,  our  effects  system  distinguishes  two  effects  on  regions:  read  and  write,  where  writ¬ 
ing  includes  the  possibility  of  reading.  Our  effects  annotations  specify  a  superset  of  the  effects 
a  program  segment  may  have  on  program  state  in  terms  of  regions  identified  by  targets — extrinsic 
identifiers  of  regions — and  enables  comparison  of  effects  to  determine  if  they  conflict:  if  at  least  one 
effect  is  a  write  and  they  affect  potentially  overlapping  targets.  Our  analyses  arc  composable,  e.g., 
a  method  body  can  be  checked  against  its  annotation  using  the  annotations  on  the  methods  it  calls. 
Similar  to  type-checking  in  the  context  of  separate  compilation,  if  all  method  bodies  arc  checked 
at  some  point,  the  program  as  a  whole  obeys  its  annotations.  To  preserve  abstraction,  an  effects 
declaration  cannot  refer  to  regions  that  arc  less  visible  than  the  method  being  annotated.  To  enable 
modular  reasoning,  a  reimplementation  of  a  method  in  a  subclass  must  conform  to  the  effects  decla¬ 
ration  in  the  superclass.  There  is  a  subtlety:  because  subclasses  can  add  fields  to  existing  regions,  it 
is  possible  for  a  method  in  a  subclass  to  affect  more  state  than  the  declaration  in  the  superclass  might 
otherwise  seem  to  allow.  To  describe  the  state  of  collaborations  of  objects,  the  region  framework  is 
extended  to  allow  state  aggregations.  Such  aggregations  allow  portions  of  state  of  one  object  to  be 
treated  as  state  of  another  object.  As  a  result,  a  complex  of  numerous  objects,  such  as  a  linked  list, 
can  be  handled  as  a  single  notional  object  comprising  a  few  regions  of  mutable  state. 

We  use  regions  and  effects  (1)  to  associate  locks  with  state,  see  Chapter  5,  (2)  to  make  verifi¬ 
cation  of  uniqueness  annotations,  described  in  Section  4.6,  composable,  and  (3)  to  support  program 
transformation,  see  Chapter  8.  In  particular,  our  effects  system  was  originally  developed  to  support 
semantics-preserving  program  manipulations  on  Java  source  code:  many  transformations  change 
the  order  in  which  computations  are  executed.  Assuming  no  other  computations  intervene  and  that 
each  computation  is  single-entry  single-exit,  it  is  sufficient  to  require  that  the  effects  of  the  two 
computations  do  not  interfere:  one  computation  does  not  write  state  that  is  read  or  written  by  the 
other. 

In  the  following  we  first  describe  in  more  detail  regions,  targets,  and  effects.  We  then  describe 
two  extensions  to  our  model  of  state  to  incorporate  aggregations  of  objects:  (1)  incorporating  the 
state  of  a  uniquely  referenced  object  into  the  state  of  the  object  the  that  refers  to  it,  and  (2)  param¬ 
eterizing  classes  by  regions  to  allow  paid  of  the  state  of  an  object  to  be  incorporated  into  the  state 
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of  another  object.  A  discussion  of  soundness  issues  follows.  After  a  review  of  related  work,  we 
present  a  formalization  of  the  effects  system  in  the  context  of  FluidJava. 


4.1  Regions  Identify  State 

To  help  answer  what  is  the  program  state,  the  programmer  defines  names  for  extensible  groups  of 
mutable  fields  called  regions.  Publicly  visible  regions  represent  the  abstract  data  manipulated  by 
the  abstract  operations  of  the  class.  The  read  and  write  effects  of  a  method  are  reported  with  respect 
to  the  regions  visible  to  the  caller.  In  this  section,  we  describe  the  general  properties  of  a  region, 
and  how  regions  arc  specified  by  the  programmer. 

4.1.1  The  Region  Hierarchy 

The  regions  of  a  program  arc  a  hierarchy:  at  the  root  of  the  hierarchy  there  is  a  single  region 
Ob  j  ect .  A1 1  that  includes  the  complete  mutable  state  of  the  program.  In  Java,  this  region  includes 
all  the  mutable  fields  of  heap-allocated  objects,  instance  variables,  plus  all  the  mutable  static 
fields,  class  variables,  of  loaded  classes.  At  the  leaves  of  the  hierarchy  are  all  the  mutable  fields 
which  again  comprise  the  entire  mutable  state  of  the  program.1 2  Thus  we  see  that  each  field  is  itself 
a  childless  region.  We  call  the  non-field  regions  abstract  regions r  A  region  name  is  identified  with 
the  class  in  which  it  is  declared,  just  as  regular  Java  fields  and  methods  arc  identified.  A  region 
name  should  not  be  confused  with  a  specific  region  of  an  object;  see  the  discussion  of  targets  in 
Section  4.2. 

The  programmer  declares  new  regions  using  class-level  program  annotations  of  the  form 

@region  visibility  [static]  region  [extends  parentRegion \ 

This  annotation  declares  a  new  region  region  in  the  annotated  class  that  extends  the  region  parent¬ 
Region  that  must  be  visible  within  the  annotated  class.  The  new  region  may  be  optionally  static, 
associating  a  single  new  region  with  the  class  itself.  A  non-static  declaration  defines  a  set  of 
regions,  one  for  each  instance  of  the  class.  The  standard  Java  visibility  modifiers  apply  to  region 
declarations  and  retain  their  usual  meaning.  If  the  parent  region  is  not  explicitly  named  then  it  is 

1  External  state  such  as  file  state  is  beyond  the  scope  of  this  work.  Suffice  it  that  special  regions  under  Al  1  can  be 
used  to  model  this  external  state. 

2We  use  the  term  abstract  to  emphasize  the  implementation  hiding  characteristics  of  these  regions,  and  not  in  the 
usual  sense  of  Java  abstract  methods  which  impose  implementation  requirements  on  subclasses. 
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the  static  region  Obj  ect  .All  for  static  regions  and  Obj  ect .  Instance  for  non-static  in¬ 
stance  regions.  These  defaulting  rules  apply  to  unannotated  field  declarations — region  declarations 
in  their  own  right — as  well. 

A  field  may  be  placed  into  a  programmer-defined  region  using  the  annotation 
@mapInto  parentRegion 

To  preserve  the  tree  nature  of  the  region  hierarchy,  the  parent  of  a  static  region  must  be  another 
static  region,  otherwise  the  region  would  in  effect  have  multiple  parents.  An  instance  region  may 
have  a  static  region  as  its  parent. 

As  alluded  to  already,  there  arc  several  predefined  regions.  Specifically,  they  arc 

•  The  static  region  Obj  ect  .All — the  root  of  the  region  hierarchy.  This  region  is  the  default 
parent  of  programmer-declared  static  regions,  and  the  ultimate  ancestor  of  every  region. 
Unannotated  methods  arc  treated  as  though  they  have  the  effect  @writes  Object  .All — 
that  is,  they  arc  treated  as  though  they  might  modify  anything. 

•  The  region  Object .  Instance,  a  subregion  of  All.  Region  Instance  is  the  default  par¬ 
ent  of  programmer-declared  instance  regions.  Instance  regions  are  not  required  to  have 
Instance  as  an  ancestor. 

•  The  region  Array.  [] ,  a  subregion  of  Instance.  In  Java,  arrays  are  objects,  so  we  model 
them  as  instances  of  a  pseudo-class  Array  with  the  region  [  ] ,  pronounced  element ?  When 
a  subscripted  element  of  an  array  is  accessed,  it  is  treated  as  an  access  of  region  [  ] . 

4.1.2  An  Example 

The  class  Point  in  Figure  4.1a  demonstrates  the  use  of  region  annotations.  The  annota¬ 
tions  declare  a  new  public  abstract  region  Position  into  which  the  private  fields  x  and  y 
are  located.  An  instance  p  of  class  Point  has  four  instance  regions:  p .  Instance,  which  con¬ 
tains  p.  Position,  which  in  turn  contains  p.x.  and  p.y.  The  region  Instance  of  p — and  of  all 
objects — is  contained  in  the  static  region  Object  .All. 

The  class  Point  has  methods  getx,  getY,  and  scale  (among  others).  The  getter  methods 
are  correctly  annotated  with  @reads  Position  and  @writes  nothing,  and  scale  is  correctly 
annotated  with  @reads  nothing  and  @writes  Position.4  Effects  annotations  arc  more  fully 

'More  precision  could  be  obtained  by  distinguishing  the  different  types  of  arrays,  especially  arrays  of  primitive  types. 

4Our  annotations  are  consistent  with  standard  Java  naming  rules  and  provide  for  omitting  this  and  the  class  name 
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I  *  * 

*  A  two-dimensional  point. 

*  @region  public  Position 

*/ 

public  class  Point  {  ... 

/**  @mapInto  Position  */ 
private  int  x; 

/**  @mapInto  Position  */ 

private  int  y; 

j  *  * 

*  @reads  Position  */ 

*  @writes  nothing 

*/ 

public  int  getX()  {  return  x;  } 
I  *  * 

*  @reads  Position  */ 

*  @writes  nothing 

*/ 

public  int  getY()  {  return  y;  } 
I  *  * 

*  @reads  nothing 

*  @writes  Position 
*/ 

public  scale (int  sc)  { 
x  *=  SC; 
y  *=  SC; 


(a) 


j  *  * 

*  A  colored  point . 

*  @region  public  Appearance 

*/ 

public  class  ColorPoint  extends  Point  { 

/**  @mapInto  Appearance  */ 

private  int  color; 

} 


/**  A  three-dimensional  point.  */ 
public  class  Point3D  extends  Point  {  . . 
/**  @mapInto  Position  */ 
private  int  z ; 

J  *  * 

*  @reads  nothing 

*  @writes  Position 

*/ 

public  void  scale (int  sc)  { 
super . scale (sc) ; 
z  *=  sc; 


(b) 


Figure  4.1:  Annotated  classes  (a)  Point;  and  (b)  ColorPoint,  and  Point3D.  Annotations  are 
shown  in  boldface. 


described  in  Section  4.3,  but  we  introduce  them  here  to  demonstrate  the  flexibility  in  state  identifi¬ 
cation  enabled  by  the  region  hierarchy.  In  general,  method  declarations  are  annotated  with  @read 
and  @write  annotations  that  list  the  portions  of  state  that  may  be  affected  by  executing  the  method. 
Returning  to  our  example,  effects  in  terms  of  x  and  y  should  not  be  used  because  the  regions  x  and 
y  are  private  but  the  methods  are  public.  Using  an  annotation  such  as  @writes  x,  y  breaks 
abstraction  by  revealing  private  implementation  details  to  clients  of  the  class  and  thus  is  disallowed. 
The  annotations  @writes  Instance  and  @writes  All — the  default  annotation — are  also  pos¬ 
sible,  and  while  they  do  not  break  abstraction,  they  are  less  precise,  as  described  in  the  continuation 
of  this  example  below. 


from  region  identifiers. 
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4.1.3  Regions  and  Subclasses 

Regions  arc  inherited  by  subclasses,  subject  to  their  visibility,  and  a  subclass  may  declare  its  own 
regions,  possibly  within  an  inherited  abstract  region.  Being  able  to  extend  existing  regions  is  critical 
to  being  able  to  specify  the  effects  of  a  method  and  later  being  able  to  meaningfully  override  the 
method.  The  intent  is  that  programmers  arc  able  to  define  regions  so  that  fields  associated  with  the 
same  abstract  design  concept  are  identified  with  the  same  region.  The  programmer  thus  produces  a 
region  hierarchy,  which,  as  alluded  to  already,  is  key  to  the  scalability  of  our  approach  by  permitting 
the  programmer  to  describe  the  state  accessed  by  a  computation  with  varying  degrees  of  precision. 

Consider  the  class  ColorPoint  in  Figure  4.1b  that  inherits  from  Point,  and  declares  field 
color  to  be  in  a  new  abstract  region  Appearance,  implicitly  a  subregion  of  Instance.  If 
ColorPoint  overrode  scale,  the  overriding  method  would  not  be  allowed  to  access  color,  that 
is,  an  analysis  to  assure  consistency  between  annotated  effects  and  implementation  would  mark  the 
method  as  erroneous.  This  is  because  color  is  not  in  Position,  which  is  reasonable  because  color 
is  not  a  position-related  property.  If  scale  were  annotated  with  the  less  precise  effect  @writes 
Instance,  the  limitation  would  be  lifted,  because  color  is  indeed  in  Instance.  At  the  extreme, 
if  the  method  were  annotated  with  @writes  Object  .All  then  the  implementation  would  be  al¬ 
lowed  to  modify  anything.  The  benefit  of  a  more  precise  annotation  is  greater  documentation  of 
programmer  design  intent,  /.<?.,  of  what  state  the  method  is  intended  to  affect,  and  thus  enables 
greater  assurance  that  an  implementation  is  compliant  with  programmer  intent.  For  example,  the 
client  of  a  compliant  implementation  of  ColorPoint  or  a  subclass  thereof  can  rely  on  the  fact  that 
invoking  scale  is  not  going  to  change  the  color  of  a  point. 

We  can  create  a  second  subclass  of  Point,  Point3D,  also  in  Figure  4.1b.  In  this  case,  the  class 
adds  an  additional  field  z  to  the  inherited  Position  region.  The  new  implementation  of  scale 
is  actually  allowed  to  access  more  state  than  the  original  implementation  because  the  Position 
region  of  Point3D  objects  is  expanded  to  include  the  additional  field.  The  implementation  of 
scale  thus  remains  consistent  with  the  original  effects  specification,  while  at  the  same  time  it  is 
able  to  expand  its  affected  state  appropriately. 


4.2  Targets  and  State  Aliasing 


In  Java,  the  handle  on  an  object  is  a  reference.  Therefore,  it  is  not  possible  to  name  a  region  of  a 
particular  object,  only  to  name  a  region  of  the  object  referenced  by  a  particular  expression.  Targets, 
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already  alluded  to,  arc  an  extrinsic  syntactic  mechanism  to  name  references  to  regions.  If  variable 
p2d  refers  to  a  Point  object,  then  target  p2d .  Position  identities  the  x  and  y  fields  of  that  object. 
But  if  p2d  refers  to  a  Point3D,  then  that  same  target  identifies  the  x,  y,  and  z  fields.  Targets  arc 
used  in  annotations  when  it  is  necessary  to  name  state.  For  example,  in  Figure  4.1,  the  declared 
effect  of  method  scale  is  that  it  writes  the  target  this .  Position.  This  target  identifies  the 
Position  region  of  the  object  referenced  by  the  method’s  receiver.  That  the  receiver  may  refer  to 
objects  of  different  classes  is  what  allows  the  target  to  identify  more  or  less  state  for  effects  checking 
purposes.  The  effect  of  an  expression  is  also  reported  in  terms  of  the  targets  that  may  be  affected. 

In  analysis,  two  targets  may  be  compared  to  determine  if  they  have  a  non-null  intersection  of 
state.  This  comparison  of  targets  involves  alias  analysis  among  program  variables  because  multiple 
targets  may  refer  to  the  same  region:  the  region  identified  by  target  pointl .  Position  is  distinct 
from  the  region  identified  by  target  point2  .  Position  only  when  pointl  and  point2  are  un¬ 
aliased.  Similarly,  aliasing  can  cause  a  single  target  to  resolve  to  multiple  possible  regions.  This 
ambiguity  motivates  our  use  of  uniqueness  annotations — see  Section  4.6 — to  enable  alias  analyses 
to  be  less  conservative  [BoyOla].  The  results  of  target  comparison  in  the  absence  of  subclasses 
are  not  violated  by  the  introduction  of  subclasses.  This  is  because  of  the  region  hierarchy  and  our 
requirement  that  subclass  definitions  respect  the  effects  declarations  in  superclasses. 

4.2.1  Kinds  of  Targets 

More  generally,  we  distinguish  between  four  forms  of  targets:  (1)  local  targets,  (2)  instance  targets, 
(3)  static  targets,  and  (4)  any-instance  targets. 

•  A  local  target  identifies  the  state  associated  with  a  local  variable  or  method  parameter.  This 
state  contains  the  value  of  the  variable,  which  is  either  a  primitive  value,  e.g.,  an  integer,  a 
boolean,  etc.,  or  a  reference  to  an  object,  but,  in  Java,  never  an  object  itself.  Local  targets  arc 
used  when  reporting  the  effects  of  expressions  within  a  method.  A  local  target  is  simply  the 
name  of  the  local  variable. 

•  An  instance  target  identifies  a  region  of  an  object.  As  described  above,  it  is  impossible  in 
Java  to  name  a  specific  object;  it  is  only  possible  to  give  an  expression  that  evaluates  to 
the  reference  to  that  object.  Because  many  different  expressions  may  evaluate  to  the  same 
reference,  instance  targets  may  be  aliased.  An  instance  target  resembles  a  standard  Java  field 
reference  expression,  except  that  abstract  region  names  arc  allowed  to  be  referenced  as  well 
as  field  names.  For  example,  if  the  expression  foo.getPoint  ()  returns  a  Point  object. 
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then  the  effect  of  invoking  f  oo .  get  Point  ( )  .  scale  ( 3 )  is  to  write  the  region  identified  by 
the  target  f  oo .  getPoint  ( )  .  Position.  The  expression  in  the  target  is  taken  in  context,  as 
described  in  Section  3.3,  and  thus  the  target  identifies  regions  based  on  the  objects  that  the 
expression  may  evaluate  to  at  a  particular  point  in  the  program. 

•  A  static  target  identifies  a  static  region.  Unlike  an  instance  region  declaration,  which 
identifies  regions  across  all  instances  of  a  class,  a  static  region  declaration  identifies  exactly 
one  region  associated  with  the  class  itself.  Thus  the  region  identified  by  a  static  target  can 
never  be  ambiguous  and  a  static  target  is  simply  the  fully  qualified  name  of  a  static  region, 
i.e.,  the  region  name  plus  the  name  of  the  class  it  is  declared  in,  as  in  Obj  ect  .All.5 

•  An  any-instance  target  identifies  state  based  on  the  name  of  an  instance  region,  refined  by  a 
class  that  constrains  the  set  of  objects  to  be  considered.  An  any-instance  target  of  the  form 
any  (class)  .  region  identifies  all  the  regions  region  of  all  the  possibly  shared  objects  of  class 
class.  In  particular,  the  target  does  not  identify  the  region  region  of  any  object  that  is  known 
to  be  uniquely  referenced.  For  example,  the  target  any  (Point )  .  Position  identifies  all  the 
Position  regions  of  all  Point  instances,  including  ColorPoint  and  Point3D  instances. 
Whereas  the  target  any  (Point3D)  .  Position  identifies  all  the  Position  regions  of  all  the 
Point3D — but  not  Point — instances. 

4.2.2  Targets  and  Method  Effects 

The  purpose  of  the  any-instance  target  requires  additional  explanation.  They  solve  a  problem  that 
occurs  when  specifying  the  effects  of  a  method.  The  declared  effects  of  a  method  must  be  in  terms 
of  state  identifiers — targets — that  arc  guaranteed  to  refer  to  the  same  state  throughout  the  execution 
of  the  method.  Otherwise  the  declared  effects  will  fail  to  account  for  all  the  effects  of  the  method, 
and  the  effects  system  will  be  unsound.  Local  targets  make  no  sense  in  the  context  of  method 
effects:  the  method  cannot  affect  the  local  state  of  the  caller,  and  the  local  state  of  the  executing 
method  disappears  once  the  method  returns.  Static  targets  refer  to  unambiguous  state,  and  arc 
therefore  acceptable  in  method  effect  declarations.  Instance  targets  arc  problematic  because  they 
arc  in  terms  of  a  general  object-valued  expression.  Consider  the  target  o .  f  .  region:  if  the  value 
in  field  f  changes  during  the  method's  execution,  the  caller  can  only  account  for  the  regions  that 
the  target  may  have  referred  to  when  the  method  was  invoked — it  has  no  information  about  what 
may  have  been  assigned  to  the  field — and  therefore  the  declared  effects  will  not  account  for  all  the 


3  Or  more  pedantically,  java .  lang.  Object  .All. 
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possible  effects  of  the  method  execution.  Spoto  and  Poll  demonstrate  the  problems  that  occur  in  this 
situation  in  the  context  of  the  assignable  clause  of  the  Java  Modeling  Language  (JML)  [SP03]. 
In  particular,  there  is  little  to  be  gained  from  the  ability  to  declare  more  precise  effects  because  they 
are  difficult  to  reason  about  and  must  generally  be  expanded  into  a  set  of  less  precise  effects. 

Because  of  these  difficulties,  we  restrict  instance  targets  in  effect  declarations  to  be  of  the  form 
p .  region,  where  p  is  a  method  parameter  or  the  receiver  this.  That  said,  the  declared  effects  of  a 
method  must  still  account  for  the  state  affected  by  expressions  such  as 

this . f 1 . f 2  =  ... 

that  appeal-  within  a  method  implementation.  When  reasoning  about  effects  within  the  method 
implementation,  the  target  this .  f  l .  f  2  is  useful,  but  as  just  described,  it  cannot  be  used  in  the 
declared  effects.  Our  effects  system  thus  contains  any-instance  targets  which  identify  regions  based 
on  classes.  They  are  easier  to  reason  about  than  the  alternatives,  and,  in  practice,  no  less  precise. 


4.3  Effects 

We  distinguish  between  two  kinds  of  effects:  read  effects,  those  that  may  read  the  contents  of 
a  region;  and  write  effects,  those  that  may  change  or  read  the  contents  of  a  region.  As  seen  in 
Section  4.1.2,  the  programmer  may  annotate  a  method  with  its  permitted  effects;  it  is  an  error 
for  any  implementation  of  the  method  to  have  more  effects  than  are  declared.  The  soundness  of 
static  analysis  of  the  effects  system  would  otherwise  be  compromised.  We  emphasize  that  effects 
are  permissive:  an  effect  describes  the  upper  bound  on  how  state  might  be  affected.  Similarly,  if  a 
region  is  affected  by  an  expression,  is  it  possible  that  only  part  of  the  region  is  affected.  For  example, 
invoking  the  method  Point .  getx  in  Figure  4.1  has  the  effect  @reads  Position  even  though  the 
implementation  actually  affects  only  the  field  x.  Because  effects  are  permissive,  a  write  effect  does 
not  guarantee  that  a  variable  is  written.  Thus  there  would  be  no  data-dependency  puipose  served  by 
not  permitting  a  write  annotation  to  give  permission  to  read — it  would  only  make  the  annotations 
more  verbose. 

Effect  annotations  are  introduced  in  Figure  4.1.  In  general,  effects  are  specified  using  the  anno¬ 
tations 

@reads  target l5  ...,  targetn 


@writes  target 1;  ...,  targetn 


and 
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where  target  is  restricted  to  be  a  static  target,  an  instance  target  identifying  a  region  of  a  method 
parameter  (including  this),  an  any-instance  target,  or  the  special  target  nothing  that  identities 
no  regions.  Section  4.11.2  describes  this  restriction  more  formally.  As  mentioned  previously, 
our  implementation  allows  this  to  be  omitted  in  targets,  thus  @reads  Instance  is  the  same 
as  @reads  this .  Instance.  Unannotated  methods  are  assumed  to  have  the  effect  @writes 
Object. All.  The  burden  of  annotating  effects  is  lightened  by  allowing  a  partial  specification 
of  effects:  if  a  @reads  annotation  but  not  a  @writes  annotation  is  present,  then  the  annotation 
@writes  nothing  is  assumed,  and  similarly  for  a  missing  @reads  annotation. 

4.3.1  Computing  Effects 

Effects  arc  computed  in  a  bottom-up  traversal  of  the  syntax  tree.  Every  statement  and  expression  has 
an  associated  set  of  effects.  In  general,  an  effect  is  produced  by  any  expression  that  reads  or  writes 
a  mutable  variable  or  mutable  object  field;  in  Java,  immutability  is  indicated  by  the  final  modifier 
in  field  and  variable  declarations.  More  specifically,  a  write  effect  directly  originates  from  an  as¬ 
signment  expression,  which  in  Java  includes  pre-  and  postfix  increment  and  decrement  operators,  or 
indirectly  from  a  call  to  a  method/constructor  with  a  write  effect.  A  read  effect  directly  originates 
from  a  variable  use  or  a  field  reference  expression,  or  indirectly  from  a  call  to  a  method/constructor 
with  a  read  effect.  Recall  that  array  subscripting  is  treated  as  a  reference  to  the  region  [] . 

The  effects  of  expressions  and  statements  include  the  union  of  the  effects  of  all  their  sub¬ 
expressions.  The  targets  in  the  computed  effects  use  the  most  specific  regions  possible.  Thus,  for 
example,  analysis  of  the  expression  this.x  *=  sc  from  the  Point,  scale  method  determines 
that  local  target  this  is  read,  instance  target  this  .  x  is  written,  and  local  target  sc  is  read.  A  more 
precise  description  of  how  effects  are  computed  for  FluidJava  is  given  in  Section  4.1 1.2. 

The  analysis  is  intraprocedural;  effects  of  method  calls  arc  obtained  from  the  annotation  on  the 
called  method,  rather  than  from  an  analysis  of  the  method’s  implementation.  Because  the  method’s 
declared  effects  arc  with  respect  to  the  formal  parameters  of  the  method,  the  effects  of  a  particular 
method  invocation  arc  obtained  by  substituting  the  actual  parameters  for  the  formal  parameters  in 
the  declared  effects. 

4.3.2  Comparing  Effects 

Assuming  the  effects  system  is  sound,  see  Section  4.9,  two  expressions  interfere ,  that  is,  have  a  data 
dependency  between  them,  only  if  they  have  conflicting  sets  of  effects.  Two  effects  conflict  if  at 
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least  one  is  a  write  effect  and  they  affect  targets  that  describe  state  that  may  overlap,  that  is,  may 
refer  to  the  same  mutable  state  at  runtime.  Two  targets  may  overlap  only  if  they  refer  to  overlapping 
regions,  and  the  hierarchical  nature  of  regions  insures  that  regions  overlap  only  if  one  is  included 
in  the  other.  Furthermore,  an  instance  target  can  only  overlap  another  instance  target  if  the  objects 
they  refer  to  could  be  identical.  The  details  of  our  implementation  arc  described  in  Section  4.1 1.4. 

4.3.3  Checking  Declared  Effects 

The  effects  of  a  method  implementation  must  be  checked  against  the  declared  effects  of  the  method. 
Every  effect  that  might  be  to  state  that  exists  prior  to  the  method  or  constructor  being  called  must 
be  accounted  for  by  the  declared  effects.  Some  implementation  effects  can  be  ignored  or  “masked,” 
because  they  arc  known  to  affect  state  that  cannot  be  observed  by  the  caller: 

•  Effects  on  local  targets  arc  masked  because  they  arc  irrelevant  outside  of  the  method's  stack 
frame. 

•  Effects  on  newly  created  objects  arc  masked  because  they  arc  imperceivable  outside  of  the 
method  body.  In  particular,  the  state  did  not  yet  exist  in  the  calling  context. 

•  For  a  constructor,  effects  on  the  object  being  constructed  can  be  ignored.  Again,  this  is 
because  the  object  did  not  exist  prior  to  the  constructor  being  called. 

Checking  that  implementation  effects  arc  consistent  with  the  declared  intended  effects  is  com¬ 
plicated  by  the  limitations  discussed  in  Section  4.2.2:  it  only  makes  sense  for  the  declared  effects 
to  use  any-instance  targets  or  instance  targets  restricted  to  refer  to  regions  of  the  objects  referenced 
by  the  method’s  parameters  (including  the  receiver  this).  Effects  inferred  from  the  method’s  im¬ 
plementation,  however,  arc  in  terms  of  more  general  targets.  We  need  to  be  able  to  determine  if 
an  implementation  effect  is  “covered”  by  the  declared  effects.  Because  any-instance  targets  cause 
effect  conflict  results  to  be  overly  conservative,  we  would  like  to  maximize  the  number  of  effects 
that  can  be  determined  to  be  covered  by  an  effect  on  a  region  of  an  object  referenced  by  a  method 
parameter.  We  define  a  general  relation  covers  that  relates  a  set  of  formal  parameter  names  to  an 
expression  from  a  method.  For  a  method  or  constructor  m,  let  e  be  an  expression  from  the  method, 
Fm  be  the  set  of  formal  parameters  of  the  method,  origf  refer  to  the  object  bound  to  the  formal 
/  G  Fm  on  entry  to  the  method  m,  and  N  be  the  set  of  objects  newly  allocated  during  execution  of 
the  method.  For  a  set  F  C  Fm,  we  say  F  covers  e  if,  for  any  call  of  the  method,  the  objects  that  e 
may  refer  to  during  the  course  of  executing  the  method,  O,  arc  such  that  0  C  N IJ  {  ong  f  G  F  \. 
That  is,  F  covers  e  if  each  object  that  e  might  refer  to  that  is  not  a  newly  allocated  object  can  be 
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proved  to  be  equal  to  orujf  for  some  /  6  F.  A  simple  approximation  of  the  covers  relation  is 

{{/}  covers  /  where  /  is  the  use  of  a  final  formal 

{}  covers  (new  c) 

Clearly,  a  write  effect  must  be  accounted  for  by  a  write  effect.  Because  write  effects  also  give 
“permission”  to  read,  however,  a  read  effect  can  be  accounted  for  by  either  a  read  or  a  write  ef¬ 
fect.  We  thus  now  discuss  informally  how  the  targets  describing  the  affected  state  arc  accounted 
for.  In  general,  the  region  hierarchy  allows  targets  at  a  coarser  granularity  to  account  for  targets 
identifying  state  at  a  finer  granularity.  Accounting  for  static  targets  and  any-instance  targets  is  thus 
straightforward.  As  mentioned  above,  local  targets  arc  masked.  Instance  targets  arc  also  straight¬ 
forwardly  accounted  for  by  static  and  any-instance  targets.  The  challenge  is  to  account  for  an  effect 
on  an  instance  target  e .  region  with  a  declared  effect  on  an  instance  target.  For  this  we  rely  on  the 
covers  relation.  If  e  is  a  method  parameter,  then  it  is  may  be  accounted  for  by  a  declared  effect  on 
a  method  parameter,  according  to  the  region  hierarchy.  Otherwise,  if  there  exists  a  set  F  such  that 
F  covers  e,  then  the  target  may  be  accounted  for  by  instead  accounted  for  all  the  instance  targets 
/ .  region,  where  /  is  an  element  of  F. 


4.4  Example:  Class  Atomiclnteger 

We  now  use  several  examples  to  demonstrate  further  the  use  of  region  and  effect  annotations,  and 
to  highlight  how  the  design  of  the  region  hierarchy  is  a  reflection  of  programmer  design  intent. 
Our  first  example  is  an  “atomic  integer”  class:  an  encapsulated  integer  value  that  is  synchronized 
for  concurrent  use.  Such  classes  exist  in  popular  concurrency  libraries,  e.g.,  Synchronizedlnt  in 
util .  concurrent  [Lea],  The  source  code  for  class  Atomiclnteger  is  shown  in  Figure  4.2.  Ob¬ 
jects  of  the  class  are  wrappers  around  an  int  field;  the  methods  provide  get,  set,  and  testAndSet 
access  to  the  value.  Access  is  synchronized  by  using  an  object  as  a  lock  to  protect  the  data.  This 
lock  may  be  the  Atomiclnteger  object  itself,  or  some  other  object  that  is  identified  when  the 
object  is  constructed. 

The  state  of  an  Atomiclnteger  consists  of  the  two  fields  lock  and  value.  These  have  been 
left  unannotated,  which  by  default  makes  them  subregions  of  Instance.  The  field  lock  is  final 
to  prevent  the  identity  of  the  lock  from  changing.  Both  constructors  are  annotated  to  have  no  effects. 
This  is  correct  because  the  constructors  only  affect  the  object’s  Instance  region,  via  the  value 
region,  so  the  effects  are  masked.  The  getLock  method  is  also  declared  to  have  no  effects.  This 
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public  class  Atomiclnteger  { 

/**  Object  to  use  as  the  mutex  to  protect  <code>value</code> .  */ 
private  final  Object  lock; 

/**  The  encapsulated  integer  value.  */ 
private  int  value; 

I  *  * 

*  Create  an  integer  that  uses  a  specific  lock. 

*  @writes  nothing 

*/ 

public  Atomiclnteger (  int  val,  Object  1  )  { 
lock  =  1 ; 
value  =  val ; 

} 


j  *  * 

*  Create  an  integer  that  uses  itself  as  the  lock. 

*  @writes  nothing 

*/ 

public  Atomiclnteger (  int  val  )  {  this (  this,  val  );  } 

j  *  * 

*  Get  the  lock  used  to  protect  this  object. 

*  @writes  nothing 

*/ 

public  Object  getLockO  {  return  lock;  } 

j  *  * 

*  Get  the  integer  value . 

*  @reads  Instance 

*/ 

public  int  get()  {  synchronized (  lock  )  {  return  value;  }  } 

j  *  * 

*  Set  the  integer  value. 

*  @writes  Instance 

*/ 

public  void  set (  int  val  )  {  synchronized (  lock  )  {  value  =  val;  }  } 
I  *  * 

*  Set  the  value  to  <code>newVal</code>  only  if 

*  the  current  value  is  <code>assumedVal</code> 

*  @return  <code>true</code>  if  the  new  value  was  set. 

*  @writes  Instance 

*/ 

public  boolean  testAndSet (  int  assumedVal,  int  newVal  )  { 
synchronized (  lock  )  { 

boolean  success  =  (assumedVal  ==  value) ; 
if (success)  value  =  newVal; 
return  success; 


Figure  4.2:  Source  code  for  Atomiclnteger  with  effects  annotations.  Annotations  arc  shown  in 
boldface. 
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declaration  is  correct  even  though  the  implementation  of  the  method  clearly  accesses  a  field.  The 
method  body  has  a  single  effect:  it  reads  local  target  this  when  referencing  the  field  lock.  Reading 
the  field  lock  produces  no  effect  because  the  field  is  final.  The  effect  on  the  local  target  is 
maskable  so  the  declared  effects  arc  correct. 

The  last  interesting  method  is  testAndSet  which  is  declared  to  have  the  effects  @reads 
nothing  and  @writes  Instance.  After  masking,  the  computed  effects  of  the  body  the  effects 
reads  this  .value  and  writes  this  .value  remain.  Because  a  write  effect  includes  the  pos¬ 
sibility  of  reading,  both  effects  arc  included  in  the  method’s  declared  effects. 


4.5  Example:  Class  BoundedFiFO 

A  more  sophisticated  example  is  the  class  BoundedFiFO,  originally  introduced  in  Section  1.3,  from 
the  Log4j  logging  library  shown  unannotated  in  Figure  1.2.  The  class  implements  a  circular  queue 
using  an  array  buf ,  with  head  and  tail  indices  first  and  next.  The  buffer  is  non-blocking:  geting 
from  an  empty  buffer  returns  null,  and  puting  to  a  full  buffer  silently  drops  the  new  event.  The 
class  is  intended  to  be  used  for  communication  between  threads.  Even  though  it  does  not  contain 
any  synchronization  code,  it  turns  out  clients  of  BoundedFiFO  objects  are  expected  to  acquire  the 
lock  on  the  FIFO  object.  In  Chapter  5  we  show  how  to  document  this  design  intent.  Client-side 
blocking  is  facilitated  by  the  methods  isFull,  wasFull,  and  wasEmpty. 

The  state  of  a  BoundedFiFO  consists  of  some  counters  that  track  the  size  of  the  buffer  and  the 
head  and  tail  pointers  plus  the  array  reference  buf.  Once  again,  because  there  are  no  annotations, 
all  the  fields  arc  assumed  to  be  subregions  of  Instance.  Because  the  methods  and  constructors 
are  unannotated  they  arc  treated  as  if  they  had  the  declared  effect  @writes  Object  .All.  All  the 
method  implementations  are,  of  course,  compatible  with  this.  But  reasoning  about  the  class  using 
effects  of  this  granularity  is  not  very  useful.  Also,  without  annotations  we  lose  programmer  design 
intent.  Ideally,  we  would  like  to  be  able  to  declare  that  each  method  affects  at  most  the  region 
identified  by  the  target  this  .  Instance,  that  is,  it  only  affects  the  receiving  object. 

It  is  tempting,  for  someone  who  understands  regions,  to  subdivide  Instance  into  two  regions, 
the  first  containing  the  fields  buf,  first,  and  next,  and  the  second  containing  the  fields  numElts 
and  size.  This  is  reasonable  because  the  “getter”  methods  getMaxSize,  length,  wasEmpty, 
wasFull,  and  isFull  do  not  affect  the  fields  in  the  first  group,  so  they  could  be  given  effects 
declarations  that  indicate  they  only  affect  a  portion  of  the  object.  This  partitioning  of  state  makes 
the  design  intent  more  explicit  than  leaving  all  the  fields  as  children  of  Instance.  In  particular,  that 
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only  get  and  put  should  affect  the  contents  of  the  buffer.  However,  it  does  not  assist  in  reasoning 
about  how  uses  of  BoundedFlFO  objects  may  conflict  because  (1)  all  the  getter  methods  have  read 
effects  only  and  thus  never  conflict  with  each  other,  and  (2)  get  and  put  potentially  write  to  both 
sets  of  fields  so  their  use  would  still  conflict  with  uses  of  the  getter  methods.  Herein,  we  decide  in 
favor  of  brevity  of  annotation  and  do  not  subdivide  the  Instance  region. 

4.5.1  Annotating  BoundedFlFO 

Our  first  attempt  at  annotating  the  effects  of  BoundedFlFO  is  shown  in  Figure  4.3,  which  also 
introduces  our  notation  for  easing  the  annotation  of  similar  methods.  The  class-level  annotation 

@methodSet  mset  =  methodi,  methodn  [,  .  .  .] 

identifies  a  set  of  methods,6 7  where  mset  is  an  identifier  not  already  used  as  the  name  of  a  method  or 
method  set.  The  optional  trailing  ellipsis  indicates  that  the  specification  of  the  set  is  incomplete  and 
that  methods  may  add  themselves  to  the  set  using  the  method-level  annotation 

@inSet  mset 

An  entire  set  may  be  annotated  using  the  class-level  annotation 

@set  mset  annotation 

where  annotation  is  a  method-level  annotation  (without  the  initial  “@”)7  Thus  the  annotations 
in  Figure  4.3  succinctly  describe  the  intent  that  the  methods  getMaxSize,  length,  wasEmpty, 
wasFull,  and  isFull  all  have  the  effect  @reads  Instance. 

As  discussed  above,  we  would  like  to  annotate  methods  get  and  put  with  @reads  nothing 
and  @writes  Instance.  Unfortunately,  if  we  were  to  do  so,  our  effects  checker  would  report  that 
the  declared  effects  do  not  account  for  all  the  effects  of  the  implementation.  This  is  because  these 
two  methods  do  affect  an  object  that  is  not  the  FIFO  object:  the  array  object  referenced  by  the  field 
buf .  Expressions  such  as  “ .  .  .  =  buf  [first]  ”  affect  the  region  []  of  the  object  referenced  by 

the  expression  this. buf.  The  declared  effects  of  the  get  and  put  methods  must  include  these 
effects.  According  to  the  discussion  in  Section  4.2.2  we  are  forced  to  annotate  that  the  get  and 
put  methods  can  affect  the  target  any  (Array)  .  [],  i.e.,  that  they  can  affect  any  array.  These 
annotations  are  not  ideal: 

6Overloaded  names  are  disambiguated  via  explicit  identification  of  their  parameter  types,  e.g.,  println  (obj  ect ) 
VS.  println  ( int ) . 

7  A  set  may  be  added  to  another  set  using  the  annotation  template  @set  Si  inset  S 2.  The  name  of  a  method  set  may 
also  appear  to  the  right  of  the  “=”  in  a  @methodSet  annotation. 
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I  *  * 

*  @methodSet  readers  =  getMaxSize,  length,  wasEmpty,  wasFull,  isFull 

*  @set  readers  reads  Instance 

*/ 

public  class  BoundedFIFO  {  ... 

LoggingEvent []  buf; 

int  numElts  =  0,  first  =  0,  next  =  0,  size; 

/  *  * 

*  @writes  nothing  */ 

public  BoundedFIFO ( int  size)  {  ...  } 

/  *  * 

*  @writes  Instance 

*  @reads  any (Array) . [] 

*/ 

public  LoggingEvent  get ( )  {  ...  } 

/  *  * 

*  @writes  Instance,  any (Array)  .  []  */ 

public  void  put (LoggingEvent  o)  {  ...  } 

} 


Figure  4.3:  Our  first  attempt  at  annotating  class  BoundedFIFO.  Notice  the  exposure  of  the  array 
effects  for  methods  get  and  put.  Annotations  are  in  boldface. 


•  From  the  point  of  view  of  reasoning  about  the  effects  of  the  class,  the  effects  of  get  and 
put  arc  surprisingly  large.  The  effects  arc  such  that  puting  an  item  to  any  BoundedFIFO 
instance  will  interfere  with  geting  an  item  from  any  other  BoundedFIFO  instance.  This  is 
surprising  because  there  is  no  reason  to  believe  that  distinct  FIFO  instances  share  state. 

•  From  the  point  of  view  of  encapsulation,  the  effects  still  leak  implementation  related  details 
to  clients  of  the  class.  Namely,  that  BoundedFIFO  is  implemented  using  an  array.  This  detail 
ought  to  be  irrelevant  to  clients. 

•  From  the  point  of  view  of  design  intent ,  the  annotations  fail  to  capture  the  intent  that  the  array 
referenced  by  the  field  buf  is  part  of  the  FIFO  object.  This  intent  is  fundamental  to  how  the 
programmers  think  about  the  class,  and  is  why  the  previous  two  points  arc  surprising  to  both 
clients  and  maintainers  of  the  class. 


4.6  State  Aggregation  through  Uniqueness 

As  the  example  above  shows,  the  state  of  a  single  design  abstraction  often  spans  the  state  of  multiple 
instantiated  objects.  This  can  interfere  with  the  clarity  of  expressed  design  intent  and  force  the 
principles  of  encapsulation  to  be  violated.  We  have  two  techniques  for  aggregating  state  from  many 
objects  into  a  single  region.  The  first  is  based  on  the  exploitation  of  unaliased  references,  also 
known  as  unique  or  unshared  references.  The  second  technique,  presented  in  the  next  section,  is 
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based  on  parameterizing  classes  by  regions. 

A  field  in  Java  contains  only  a  reference  to  an  object.  Thus  a  region  does  not  contain  the  state  of 
other  objects,  only  references  to  other  objects.  The  intent  for  class  BoundedFlFO,  however,  is  that 
the  state  of  the  FIFO  also  include  the  entirely  separate  array  object  referenced  by  the  field  buf .  In 
Section  4.5  we  discuss  some  of  the  problems  that  result  from  the  failure  to  capture  this  design  intent. 
The  programmer  is  inclined  to  think  that  the  state  of  the  array  is  part  of  the  FIFO  object  because  of 
the  additional  intent  that  the  array  referenced  by  buf  is  not  intended  to  be  shared  with  other  objects. 
That  is,  the  reference  is  meant  to  be  unique.  State  of  a  uniquely  referenced  object  may  be  considered 
to  be  state  of  the  referencing  object.  In  particular,  regions  of  the  referenced  object  are  mapped  back 
into  regions  of  the  referencing  object.  This  mapping  can  be  performed  only  for  uniquely  referenced 
objects.  Consider  the  case  of  an  object  referenced  by  two  different  objects  that  both  map  its  state 
into  their  own.  Suppose  that  the  two  referring  objects  arc  visible  in  the  same  scope  via  variables  p 
and  q,  and  alias  analysis  is  able  to  determine  that  they  are  not  aliased.  Because  effects  on  our  shared 
object  through  p  arc  now  treated  as  effects  on  p  and  because  effects  on  our  shared  object  through  q 
arc  now  treated  as  effects  on  q,  we  can  falsely  conclude  that  two  writes  to  the  same  region  of  our 
shared  object  do  not  conflict. 

We  use  the  field-level  annotation 
@unshared 

to  record  explicitly  the  design  intent  that  the  field  has  no  aliases  at  all  when  it  is  read,  that  is, 
any  object  read  from  it  is  not  accessible  through  any  other  variable.  A  separate  composable  static 
analysis,  described  in  [BoyOla],  verifies  that  unshared  fields  arc  properly  used.  The  analysis  also 
supports  @unshared  method  parameters  and  return  values,  and  ©borrowed  parameters — variables 
for  which  no  new  aliases  may  be  created.  Further  discussion  on  these  features  is  beyond  the  scope  of 
this  work,  although  we  rely  on  the  design  intent  they  express  for  several  of  the  analyses  we  present 
herein.  Once  a  field  has  been  identified  as  unaliased,  it  is  possible  to  treat  the  object  referenced  by 
that  field  as  paid  of  the  referring  object.  The  instance  regions  of  a  uniquely  referenced  object  may 
be  aggregated  into  regions  of  the  referring  object  using  the  field-level  ©aggregate  annotation: 

©aggregate  Si  into  d\  ,  . . . ,  sn  into  dn 

This  declares  the  intent  that  region  ■%  of  the  uniquely  reference  object  is  aggregated  into  the  region 
di  of  the  referring  object.  That  is,  effects  on  region  Si  of  the  referenced  object  arc  considered  to  be 
effects  on  region  di  of  the  referring  object. 

Two  regions  related  by  the  region  hierarchy  must  not  be  mapped  into  unrelated  regions.  Suppose 
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*  @methodSet  readers  =  getMaxSize,  length,  wasEmpty,  wasFull,  isFull 

*  @set  readers  reads  Instance 

*/ 

public  class  BoundedFIFO  {  ... 

I  *  * 

*  @unshared 

*  ©aggregate  Instance  into  Instance 

*/ 

LoggingEvent []  buf; 

/  *  * 

*  @writes  Instance  */ 

public  LoggingEvent  get ( )  {  ...  } 

/  *  * 

*  @writes  Instance  */ 

public  void  put (LoggingEvent  o)  {  ...  } 


Figure  4.4:  Class  BoundedFIFO  annotated  to  use  uniqueness  aggregation.  The  effects  of  get  and 
put  no  longer  reveal  array  effects.  Annotations  arc  in  boldface. 


(1)  region  p  is  a  subregion  of  r  in  an  unshared  object;  (2)  they  arc  mapped  into  regions  a  and  b  of 
the  referencing  object,  respectively;  and  (3)  neither  a  nor  b  is  a  descendent  of  the  other.  A  write 
to  region  p  of  the  unshared  object  should  conflict  with  a  write  to  region  r,  but  via  mapping  we 
can  falsely  conclude  that  they  do  not  conflict  because  regions  a  and  b  of  the  referencing  object  arc 
disjoint.  We  additionally  require  the  mapping  to  respect  the  ancestor-descendent  relationship  to 
prevent  potential  logical  inconsistencies  and  unsoundness  in  the  formalization  of  the  semantics  of 
the  effects  system.  Specifically,  if  region  r  of  unshared  field  u  is  aggregated  into  region  q  of  the 
referring  object,  then  any  descendent  of  r  must  be  aggregated  into  a  descendent  of  q,  or  q  itself.  We 
also  require  that  all  regions  of  the  uniquely  referenced  object  must  be  mapped  into  some  region  of 
the  referring  object.  That  is,  for  a  uniquely  referenced  object  declared  to  be  of  class  c,  we  require 
that  for  each  region  in  c  there  exists  a  superregion  of  c  that  is  explicitly  mapped  into  the  referring 
object. 

Returning  to  class  BoundedFIFO  we  can  use  annotations  to  capture  the  design  intent  that  the 
array  referenced  by  buf  is  meant  to  be  paid  of  the  FIFO  object  itself.  The  field  is  declared  to  be 
@unshared  and  the  Instance  region  of  the  referenced  array,  which  includes  the  []  region,  is 
aggregated  into  the  FIFO's  Instance  region;  see  Figure  4.4.  Static  analysis  assures  that  buf ’s  use 
is  consistent  with  being  unshared.  Effects  analysis  is  now  able  to  determine  that  put  and  get’s 
effects  to  the  array  are  included  in  effects  to  the  FIFO  object  itself.  Both  methods  can  thus  be 
annotated  with  the  more  precise  effect  @writes  Instance. 

When  checking  that  an  implementation’s  effects  arc  consistent  with  the  method’s  declared  ef- 
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fects,  effects  on  ©unshared  parameters  can  be  ignored.  Because  the  method’s  caller  must  “give  up” 
access  to  such  an  object,  it  cannot  observe  any  future  changes  to  that  object’s  state.  Additionally, 
the  aggregation  mappings  of  (©unshared  fields  are  consulted  to  reinterpret  effects  on  a  referenced 
object  into  effects  on  the  referencing  object,  which  allows  effects  that  would  otherwise  have  to  be 
accounted  for  via  any-instance  targets  to  be  accounted  for  by  effects  on  regions  of  the  method’s 
parameters  (including  this). 


4.7  State  Aggregation  through  Parameterization 

A  second  kind  of  aggregation  is  achieved  by  parameterizing  class  definitions  by  regions.  This 
technique  allows  portions  of  an  object  to  be  aggregated  into  another  object,  and  does  not  impose 
any  aliasing  constraints.  We  use  a  notation  similar  to  C++  templates.  Figure  4.5  shows  a  pair 
of  classes  from  the  Jigsaw  open-source  Java  web  server  with  annotations.  Class  ThreadCache 
maintains  a  doubly  linked  list  of  CachedThread  objects.  The  annotations  express  the  intent  that  the 
backbone  of  the  linked  list  referenced  by  ThreadCache .  freelist  be  treated  as  a  single  named 
abstract  entity  even  though  its  implementation  is  distributed  over  many  objects:  the  freelist 
and  freetail  fields  of  one  ThreadCache  and  the  next  and  prev  fields  of  the  many  linked 
CachedThreads.  The  backbone  abstraction  is  made  explicit  by  aggregating  all  these  fields  into  a 
single  region  Threads  of  a  ThreadCache  object.  This  region  is  declared  on  line  2.  The  head  and 
tail  pointers,  freelist  and  freetail,  are  declared  on  line  11  to  be  subregions  of  Threads. 

To  perform  the  intended  aggregation,  there  must  be  an  identification  for  each  CachedThread 
object  of  which  region  is  to  contain  its  fields  next  and  prev.  The  region  parameter  Backbone, 
declared  in  angle  brackets  on  line  34,  accomplishes  this.  Fields  next  and  prev  are  made  children 
of  the  region  bound  to  Backbone  on  line  41.  The  parent  region  (bound  to  Backbone)  is  specified 
when  a  CachedThread  object  is  instantiated.  This  binding  conceptually  occurs  on  line  16  when  a 
new  CachedThread  instance  is  created:  the  constructor  call  includes  the  target  this .  Threads. 
Thus  CachedThreads  created  by  different  ThreadCache  objects  arc  parameterized  by  different 
regions. 

As  in  other  polymorphic  systems,  all  uses  of  the  class  name  CachedThread  specify  a  value  for 
the  region  parameter  (specified  by  a  target);  see  lines  12,  15,  20,  and  42.  The  declaration  on  line  42 
ensures  that  a  CachedThread  can  refer  only  to  other  CachedThreads  parameterized  by  the  same 
region. 

The  parameterization  of  CachedThread  enables  enforceable  separation  between  representa- 
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1  /** 

2  *  @region  public  Threads 

3  *  @region  public  Cachelnfo 

4  */ 

5  public  class  ThreadCache  { 

6  /**  @mapInto  Cachelnfo  */ 

7  protected  int  threadcount ,  usedthreads ; 

8 

9  ... 

10 

11  /**  @mapInto  Threads  */ 

12  protected  CachedThread  /*@<this . Threads>*/  freelist,  freetail; 

13 

14  private  synchronized 

15  CachedThread  /*@<this . Threads>*/  createThread ( )  {  ... 

16  return  new  CachedThread  /*@< this . Threads>*/  (this,  ...); 

n  } 

18 

19  /**  @writes  t . Threadlnf o,  this . Instance  */ 

20  synchronized  boolean  isFree (CachedThread  /*@<this . Threads>*/  t,  ...)  { 

21  if  (  ! t . isTerminated ( ) )  {  ...  } 

22  else  {  ... 

23  t.prev  =  freetail; 

24  if  (freetail  !=  null)  freetail . next  =  t; 

25  freetail  =  t; 

26  if  (freelist  ==  null)  freelist  =  t; 

27  usedthreads--;  ... 

28  }  •  •  • 

29  } 

30  ... 

31  } 

32 

33  /**  @region  public  Threadlnfo  */ 

34  class  CachedThread  /*@<region  Backbone>*/  extends  Thread  { 

35  private  final  ThreadCache  cache; 

36  /**  @mapInto  Threadlnfo  */ 

37  private  boolean  alive; 

38  /**  @mapInto  Threadlnfo  */ 

39  private  Runnable  runner; 

40  //  [code  omitted] 

41  /**  @mapInto  Backbone  */ 

42  CachedThread  /*@<Backbone>*/  next,  prev; 

43 

44  /**  @writes  Threadlnfo  */ 

45  synchronized  boolean  isTerminated ( )  {  ...  } 

46 

47  ... 

48  } 


Figure  4.5:  Annotated  versions  of  ThreadCache  and  CachedThread. 
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tions  of  distinct  ThreadCache  aggregations,  and  also  enables  effects  analysis  to  be  less  conserva¬ 
tive  with  respect  to  the  uses  of  next  and  prev  fields  within  the  implementation  of  ThreadCache 
because  the  aggregation  adds  structure  to  the  region  hierarchy. 

In  Section  5.1,  we  show  how  to  document  the  association  of  a  lock  with  this  aggregate  region. 
Once  this  association  is  documented,  the  combined  analyses  (primarily  effects  and  aliasing,  as  noted 
above)  can  provide  assurance  that  the  critical  shared  state  is  accessed  only  when  the  correct  locks 
arc  held.  In  general,  a  class  is  parameterized  by  adding  the  annotation 

/*  @<  region  region1 ,  region  regionn>  */ 
to  a  class  definition.  Uses  of  the  class  are  parameterized  by  appending  to  the  use  the  annotation 

/*  @<  target  i ,  ...,  targetn>  */ 


4.8  Java  Interfaces 

Our  effects  system  must  accommodate  additional  complexities  of  the  Java  language  if  it  is  to  be 
adoptable  on  real  programs.  In  particular,  to  be  more  broadly  applicable  to  production  code,  our 
effects  system  must  incorporate  Java  interfaces,  which  only  declare  methods  but  never  provide  im¬ 
plementations.  A  class  may  implement  multiple  interfaces.  To  permit  useful  annotations  on  method 
headers  in  interfaces,  we  must  be  able  to  add  abstract  regions  to  interfaces  and  thus  we  must  handle 
multiple  inheritance  of  instance  regions.  Static  regions,  like  static  fields,  arc  not  inherited  and  thus 
do  not  complicate  matters.  Multiple  inheritance  of  instance  regions  is  handled  by  permitting  a  class 
or  interface  inheriting  regions  from  an  interface  to  map  them  into  other  regions  as  long  as  the  region 
hierarchy  is  preserved.  As  with  the  mapping  of  regions  in  uniqueness  aggregations,  any  two  regions, 
both  of  which  arc  visible  in  a  superclass  or  superinterface  of  the  classes  or  interfaces  performing  the 
mapping,  must  have  the  same  relationship  when  mapped  to  regions  in  the  inheriting  class  as  they 
do  in  their  original  class  or  interface.  Conflicting  relations  in  superclasses  or  superinterfaces  may 
forbid  certain  inheritance  combinations.  We  have  not  yet  formalized  or  implemented  this  aspect  of 
the  effects  system. 


4.9  Towards  Soundness 

An  important  aspect  of  a  static  effect  system  is  for  it  to  be  sound,  that  is,  it  must  not  say  two  com¬ 
putations  do  not  interfere  through  the  access  of  some  shared  state  when  in  fact  they  do.  Proving 
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soundness  requires  a  runtime  definition  of  interference  which  we  must  then  show  is  conservatively 
approximated  by  our  analysis.  The  runtime  state  of  the  program  we  arc  interested  in  includes  fields 
of  reachable  objects  as  well  as  the  state  of  local  variables  and  temporaries  in  all  activation  frames. 
The  effects  of  a  computation  can  then  be  seen  as  reads  and  writes  on  elements  of  the  state.  These  ef¬ 
fects  can  then  be  compared  to  that  of  the  second  computation.  Interference  occurs  when  an  element 
of  state  is  written  by  one  computation  and  read  or  written  by  the  other. 

We  have  not  yet  formulated  such  a  soundness  proof.  The  primary  impediment  is  the  develop¬ 
ment  of  a  type-system  and  state  semantics  that  adequately  incorporates  unshared  references  and 
the  state  aggregation  they  enable.  Even  though  we  present  here  our  effects  system  as  a  client  of 
our  system  for  assuring  unique  references,  the  two  systems  arc  in  fact  interdependent.  As  we  have 
discussed  herein,  the  effects  system  uses  uniqueness  to  enable  state  aggregations.  However,  as¬ 
suring  uniqueness  requires  effects,  in  particular  to  assure  that  unique  references  arc  not  read  when 
borrowed  references  arc  live.  This  interdependence  is  described  in  more  detail  in  [BoyOlb].  The 
interdependence  of  the  two  systems  means  that  they  cannot  be  proven  sound  independently.  A  satis¬ 
factory  combination  of  uniqueness  and  effects  has  not  been  developed.  Capabilities,  also  known  as 
permissions,  arc  presently  being  explored  as  a  solution  to  this  problem.  In  the  realm  of  uniqueness, 
Boyland,  et  al.  [BNR01]  use  capabilities  to  give  a  semantics  for  uniqueness  without  effects. 

Permissions  are  useful  for  describing  effects  as  well,  and  in  fact  provide  a  solution  to  a  tricky 
analysis  problem.  Aliasing  frustrates  reasoning  about  effects  because  effects  do  not  include  enough 
information  to  perform  interference  checking.  In  our  effects  system,  this  is  manifest  (1)  in  our  use 
of  targets  and  (2)  the  need  to  use  an  alias  analysis — unrelated  to  the  unique  analysis — to  compare 
targets.  Furthermore,  we  have  a  non-traditional  aliasing  problem  that  we  call  MayEqual  [BG99], 
although  it  can  be  approximated  using  more  traditional  alias  analyses:  we  must  determine  whether 
two  expressions,  each  at  a  different  point  in  the  program,  may  point  to  overlapping  sets  of  locations. 
Clarke  and  Drossopoulou  have  the  same  problem,  but  directly  incorporate  a  simple  type -based  alias 
analysis  into  their  effects  system  [CD02],  Interpreting  effects  as  permissions  to  read  or  write  mem¬ 
ory  locations  avoids  this  problem,  but  early  permission  systems  could  not  adequately  distinguish 
read  from  writes.  Boyland’s  “fractional  permissions”  [Boy03a]  overcome  this  difficulty,  and  he 
shows  how  to  check  read  and  write  effects  with  permissions,  although  the  system  does  not  feature 
uniqueness  or  state  aggregation. 

The  current  approach  to  integrating  uniqueness  and  effects  is  based  on  “adoption  and  focus” 
as  presented  in  the  context  of  the  Vault  programming  language  [FD02].  This  model  is  attractive 
because  it  combines  lineality,  e.g.,  uniqueness,  with  permissions,  but  as  described  is  not  sufficient 
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for  modeling  our  effects  system.  In  [Boy03b],  Boyland  extends  the  adoption  and  focus  model  with 
fractional  permissions,  multi-focus,  and  adoption  of  fields  to  enable  distinguishing  of  reads  from 
writes,  aggregation  of  multiple  objects  at  once,  and  modeling  of  hierarchical  regions,  respectively. 
In  summary,  proving  the  soundness  of  the  effects  system  is  difficult  because  of  the  interdependence 
of  uniqueness  and  effects.  Ongoing  research,  however,  on  the  integration  of  permission  systems, 
lineal-  pointers,  and  regions  appeal's  to  be  close  to  producing  a  system  upon  which  our  particular 
uniqueness  and  effects  systems  can  be  proved  sound. 


4.10  Related  Work 

Reynolds  [Rey78]  showed  how  interference  in  Algol-like  programs  could  be  restricted  using  rules 
that  prevent  aliasing.  His  technique,  while  simple  and  general,  requires  access  to  the  bodies  of 
procedures  being  called  in  order  to  check  whether  they  operate  on  overlapping  global  variables. 
The  work  includes  a  type  system  with  mutable  records,  but  the  records  cannot  have  recursive  type; 
in  particular,  lists  and  trees  are  not  possible. 

Effects  were  first  studied  in  the  FX  system  [GJLS87],  a  higher-order  functional  language  with 
reference  cells.  The  burden  of  manual  specification  of  effects  is  lifted  through  the  use  of  effects 
inference  as  studied  by  Gifford,  Jouvelot,  and  Talpin  [JG91,  TJ92],  The  work  was  motivated  by 
a  desire  to  use  stack  allocation  instead  of  heap  allocation  in  mostly  pure  functional  programs,  and 
also  to  assist  parallel  code  generation.  The  approach  was  demonstrated  successfully  for  the  former 
purpose  in  later  work  [AFL95,  TT94].  These  researchers  also  make  use  of  a  concept  of  disjoint 
“regions”  of  mutable  state,  but  these  regions  are  global,  as  opposed  to  within  objects.  In  the  original 
FX  system,  effects  can  be  verified  and  exploited  in  separately  developed  program  components. 

Jackson’s  Aspect  system  [Jac95]  uses  an  abstraction  mechanism  similar  to  our  regions  to  specify 
the  effects  of  routines  on  abstract  data  types.  He  uses  specifications  for  each  procedure  to  allow 
checking  to  proceed  in  a  modular  fashion.  In  his  work,  however,  the  specifications  are  necessary 
effects  and  are  used  to  check  for  missing  functionality. 

Extended  Static  Checking  for  Java  (ESC/Java)  [FLL+02,  DLNS98]  is  a  theorem-prover-based 
approach  for  verifying  general  properties  of  Java  programs.  Programs,  together  with  annotations 
from  a  subset  of  the  Java  Modeling  Language  [LBR99],  are  compiled  into  verification  conditions  to 
be  proved.  Regarding  effects,  our  system  distinguishes  both  read  and  write  effects  and  enforces  de¬ 
clared  effects  as  an  upper  bound  on  the  effects  of  methods,  whereas  ESC/Java  is  primarily  concerned 
with  write  effects  and  does  not  enforce  effects  declarations.  ESC/Java  does  not  support  unique  ref- 
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erences.  It  is  not  possible  to  abstract  state — fields — into  named  aggregates,  nor  is  it  possible  to 
express  state  abstractions  across  aggregates  of  objects. 

Leino,  et  al.  [Lei98,  LPHZ02]  describe  “data  groups”  as  a  means  to  abstractly  identify  object 
state.  Like  our  regions,  data  groups  are  hierarchical  sets  of  fields.  Unlike  our  regions,  a  field  or  data 
group  may  be  included  in  multiple  parent  groups.  This  is  sound  because  they  arc  not  intrinsically 
interested  in  object-oriented  effects,  but  in  using  modifies  clauses  on  methods  to  check  program 
assertions  modularly.  Thus  their  presentation  of  data  groups  does  not  include  read  effects.  State 
aggregation  akin  to  our  uniqueness  aggregation  is  possible  via  so-called  “rep  inclusions”  in  which 
the  fields  of  a  referenced  object  arc  mapped  into  the  data  groups  of  the  referring  object.  The  field 
that  refers  to  the  mapped  object  is  known  as  a  pivot  field.  Soundness  is  maintained  by  restricting 
the  use  of  pivot  fields.  Like  our  uniqueness  aggregation,  these  restrictions  amount  to  controlling 
aliasing  of  pivot  fields,  although  in  our  work  we  rely  on  a  separately  formalized  and  more  general 
uniqueness  analysis.  One  restriction  “ensures  that  values  in  pivot  fields  arc  either  null  or  unique, 
except  possibly  for  copies  stored  in  [read-only]  formal  parameters  on  the  call  stack.”  The  second 
restriction  controls  how  pivot  fields  may  be  passed  as  parameters:  it  prohibits  the  value  of  a  pivot 
field  from  being  passed  to  a  method  whose  modifies  clause  declares  that  it  may  modify  the  state  of 
the  object  referenced  by  the  pivot  field. 

Object  ownership  models  [CPN98]  transitively  aggregate  the  state  of  an  object  into  the  state 
of  its  owner.  Object  ownership  allows  aggregation  only  at  the  granularity  of  objects.  Our  region- 
based  approach  instead  models  what  might  be  called  field  ownership  and  is  not  primarily  concerned 
with  the  objects  referenced  by  fields.  Clarke  and  Drossopoulou  [CD02]  describe  an  object-oriented 
effects  system  where  state  aggregation  is  based  on  object  ownership  instead  of  unique  references, 
as  is  used  in  our  approach.  Objects  arc  not  subdivided  into  regions  of  state,  although  they  briefly 
suggest  how  this  might  be  integrated  into  their  approach.  Instead  effects  arc  reported  using  “effect 
shapes”  that  describe  sets  of  objects  based  on  the  object-ownership  tree.  The  effect  shape  this  .  l, 
for  example,  denotes  the  set  of  objects  owned  by  this,  whereas  the  shape  under  (this .  2 )  is 
the  set  of  objects  at  least  two  steps  from  this  in  the  ownership  tree.  This  representation  allows 
“the  abstract  representation  of  effects  on  unknown  pa  its  of  an  object’s  internals,  while  retaining 
some  precision  when  dealing  with  these  internals.”  Our  use  of  uniqueness  aggregation  does  not 
distinguish  between  the  levels  of  indirection.  Their  effect  system  is  thus  “orthogonal”  to  ours: 
their  precision  is  horizontal  over  a  tree,  ours  is  vertical.  We  can  distinguish  multiple  regions  of  an 
object  with  transitive  mapping  for  ownership.  Their  system  sees  only  one  region  for  all  fields  of 
an  object  but  can  distinguish  how  far  away  it  is  from  the  root  object.  Their  effect  system  does  not 
report  effects  on  local  variables — they  are  always  immutable.  Aliasing  problems  arc  not  directly 
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addressed,  instead  type-based  disjointness  is  relied  upon. 

Boyapati  and  Rinard  describe  a  ownership-based  type-system  to  enforce  locking  conventions  in 
Java  [BR01].  Classes  arc  parameterized  by  owners,  which  arc  provided  when  an  object  is  created. 
A  special  unique  owner  identities  objects  that  must  always  be  unaliased;  our  system  is  instead 
concerned  with  unaliased  variables,  which  may  only  hold  unique  references.  The  readonly  owner 
identities  immutable  objects.  Uniqueness  and  immutability  are  enforced  through  a  simple  effects 
system  that  records  aliasing  and  write  effects  that  do  not  occur  over  specific  method  parameters  or 
local  variables. 

Yates  describes  preliminary  work  on  a  type-and-effect  system  for  encapsulating  memory  in  Java 
[Yat99].  His  system  is  closer  to  that  of  [LG88]  than  it  is  to  ours.  The  state  of  the  program  is  divided 
into  disjoint  regions  that  contain  objects  in  their  entirety.  Objects  may  refer  to  objects  in  other 
regions.  Read  and  write  effects  arc  not  distinguished — an  effect  is  just  the  name  of  a  region.  Yates 
gives  a  type  system  and  semantics  for  an  elaborated  language  in  which  methods  are  elaborated  with 
the  region  in  which  their  parameters  and  return  value  reside.  These  elaborations  arc  not  polymorphic 
and  the  process  by  which  a  program  is  elaborated  is  left  unspecified.  Thus  the  number  of  regions 
in  a  program,  or  even  their  origin  is  left  unspecified.  His  goal  is  not  to  describe  design  intent  or  the 
organization  of  program  state  but  to  prove  the  correct  use  of  encapsulated  expressions,  identified  by 
a  new  keyword.  An  encapsulated  expression  is  one  that  “should  produce  the  same  result  from  the 
same  arguments  in  any  context.” 

Bierman  and  Parkinson  [BP03]  formalize  a  subset  of  our  effects  system  as  presented  in  [GB99] 
and  provide  a  effects  inference  algorithm.  The  formalization  is  proved  to  be  sound  and  the  algorithm 
correct  with  respect  to  an  operation  semantics  of  effects.  The  effects  system  they  formalize  does 
not  distinguish  between  objects — all  abstraction  regions  arc  static.  Their  system  also  lacks  a  region 
hierarchy,  uniqueness,  and  therefore,  uniqueness  aggregation. 


4.11  Effects  in  FluidJava 

We  now  present  a  subset  of  our  effects  system  more  formally  by  extending  FLUiDjAVAwith  regions, 
effects  declarations,  uniqueness,  and  uniqueness  aggregation.  We  mean  to  include  normally  de¬ 
clared  fields  when  we  use  the  term  region.  We  use  abstract  region  when  we  do  not  intend  to  include 
fields.  Because  FluidJava  does  not  have  static  fields  our  presentation  of  regions  does  not  include 
static  regions  or  static  targets.  In  particular  we  do  not  have  the  region  Object. All — the  target 
any  (Object)  .  Instance  is  sufficient  to  refer  to  all  the  heap  state  in  the  program.  We  have  not 
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defn 
region 
field 
shared_field 
unshared  _Jield 
agg 

meth 

effect 

tgt 


class  cn  extends  c  effect  {region*  field*  meth*} 
region  argn  in  argn 
shared_feld  \  unshared_feld 
mod_t  fd  in  argn  =  e 

unshared  mod_t  fd  in  argn  aggregate  agg+  =  e 
rgn  into  argn 

t  mnibfarg*)  effect  {body} 
reads  tgt+  writes  tgt+ 
nothing  j  x  \  e.rgn  |  any(c). rgn 


The  disjoint  name  spaces  are  extended  with  the  set  of  abstract  region  names;  the  set  of  region  names 
is  the  set  of  abstract  region  names  together  with  the  set  of  field  names. 

argn  £  abstract  region  names  rgn  £  field  names  U  abstract  region  names 

Figure  4  (S'  Syntax  modifications  to  Ft  mnlAVAwith  lnheled  expressions  for  regions  and  effects _ 


yet  formalized  region  parameters,  although  in  general  they  could  be  handled  by  associating  a  func¬ 
tion  with  each  parameterized  class  that  represents  the  portion  of  the  region  hierarchy  defined  by  the 
region  parameters  of  that  class,  and  by  extending  the  environment  to  map  formal  region  parameters 
to  targets.  The  subregion  relation  would  then  be  replaced  with  a  subtargeting  relation  defined  in 
terms  of  inferences  based  on  the  environment  and  relevant  portions  of  the  region  hierarchy. 


4.11.1  The  Extended  Language 

The  syntax  of  FluidJava  with  labeled  expressions  is  modified  as  shown  in  Figure  4.6.  Region  dec¬ 
larations  are  added  to  class  definitions,  and  field  declarations  must  now  include  a  parent  region.  A 
field  may  be  declared  to  be  unshared,  and  such  fields  also  have  a  mapping  from  regions  of  the  refer¬ 
enced  object  into  regions  of  the  referring  object.  A  class  declaration  now  contains  a  declaration  of 
effects:  these  are  the  effects  of  constructing  a  new  instance.  In  real  Java,  the  constructors  are  anno¬ 
tated  with  effects  just  as  methods  are.  Method  declarations  arc  extended  to  include  a  declaration  of 
their  latent  effects.  The  general  syntax  for  effects  and  targets  is  also  shown  in  Figure  4.6  and  defines 
the  set  of  effects  and  targets  used  our  in  formalizations.  Targets  are  the  empty  target  nothing,  the 
local  target  x,  the  instance  target  e.rgn,  and  the  any-instance  target  any {c).rgn.  In  Section  4.11.2, 
we  present  well  formedness  rules  that  restrict  the  shape  of  targets  in  effect  declarations. 

For  convenience,  we  abuse  notation  in  the  following  ways 

•  We  treat  members  of  tgt*  as  sets  of  targets. 

•  We  treat  the  empty  target  nothing  as  the  empty  set. 
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RegionsOnce(P)  = 

FieldsOnce(P) 

A  ( \/argn ,  argn'  :  class  •■■{■■■  region  argn  ■  ■  ■  region  argn1  ■  ■  ■}  is  in  P  =4-  argn  A  argn’) 

e.rgn  £EC  c  44  (class  c  •••{••  •  region  rgn  •  •  •}  is  in  P)  V  (3 mod_t  :  (e.rgn,  mod_t)£ic c) 

c' .rgn  £c  c  44  c’ .rgn  SEC  c'  A  c  <c  c' 

rgn  A>  c' .rgn  44  3 c!  :  c! .rgn  £c  c 

e.rgn  -4r  e! .rgn'  44  class  c  •  •  ■  {■  •  •  rgn  in  rgn'  ■  ■  ■}  is  in  P  A  c' .rgn'  £c  c 

<r  =  the  transitive,  reflexive  closure  of  P 

r9n  c'  r9n'  ^  r9n  e.rgn  A  rgn'  A>  c' .rgn'  A  e.rgn  <r  c' .rgn' 

WFRegions(P)  =  <r  is  antisymmetric 

CompleteRegions(P)  =  rng(^:r)  C  dom(P)  U  {Object. Instance} 

NoShadowing(P)  =  ...  A  (c.rgn^Pc  =4  [fle'  :  c  A  c'  A  c  <c  c’  A  c! .rgn^P c')) 

AggregationsOK(P)  =  Vc,  c' ,  rgn,  argn  : 

class  c'  ■■■{■■  ■  unshared  [final]opt  c  -  ■  ■  aggregate  ■  •  •  rgn  into  argn  ■  ■  ■  =  ■  ■  •}  is  in  P 

=4  rgn  e.rgn  A  argn  <—>  c' .argn 

MCfd(c.rgn )  =  c' .argn  44 

class  d  •••{••  •  unshared  [final]opt  cfd-  ■  ■  aggregate  •  •  •  rgn  into  argn  •••  =  •••}  is  in  P 

A  rgn  >—>  e.rgn  A  argn  A>  c' .argn 

MapOK(P,  M,c)  = 

(V (ci. rgn,  C2- argn)  £  M,  (C3. rgn' ,C4. argn')  £  M  :  ci.rgn  <r  cz.rgn’  =4  c^.argn  <r  d.argn') 

A  (Vc' .rgn'  £c  c  :  3c.rgn  £  dom(Af)  :  c' .rgn'  <r  e.rgn) 

(mn,ti . .  .tn  — »  t,(x i . . .  x„),  e)^  c 

44 

class  c  -  ■■{■■■  t  mni6i([final]ODt  h  [xijibh  ■  ■  ■  [final]ODt  tn  [xn]ibin)  reads  R  writes  W  { e}  •  •  •}  is  in  P 

ClassMethodsOK(P)  =  Vc,  c! ,  e,  e' ,  mn,  U,  t(,  t,  t' ,  V,  V' ,  ip,  ip'  : 

((mn,  h  . . .  tn  t,  V,  e)£Lc c  A  (mn,  t'\  . . .  t'n  t' ,  V' ,  e')£cc') 

=4  ((t  =  t'  A  U  =  t'i  A  V  =  V'  A  ip  =  ip')  V  (c  Ac  c')) 

fx 

c  i — r  reads  R  writes  W  44  class  c  •  •  ■  reads  R  writes  W  {■  ■  ■}  is  in  P 

Figure  4.7:  Additional  predicates  and  relations  for  checking  FluidJava  extended  with  regions  and 
effects.  Metavariables  R  and  W  arc  lists  ( tgt{  . . .  tgtn). 


•  We  treat  an  effect  reads  tgtf , . . . ,  tgt ^  writes  tgt)v , . . . ,  tgt^  as  the  set  |J™=1{reads  tgt[{ } U 
\JjLi {writes  tgt 3W},  and  vice  versa. 

•  If  ip  G  effect  then  ip[e/v\,  where  v  is  a  variable  name  or  this  and  e  is  an  expression,  is  the 
set  of  effects  where  targets  of  the  form  v.rgn  arc  replaced  with  the  target  e.rgn.  In  particular, 
substitution  does  not  occur  for  v’s  that  appeal-  within  an  expression  e. 

Additional  predicates  and  relations  necessary  for  insuring  the  region  hierarchy  is  well  formed 
are  shown  in  Figure  4.7.  Recall  that  the  set  of  region  names  is  the  union  of  the  set  of  abstract  region 
names  and  the  set  of  field  names.  We  thus  replace  the  predicate  FieldsOnce(P)  with  the  predicate 
RegionsOnce(P)  to  enforce  that  region  names  are  unique  within  a  class.  To  check  that  regions 
form  a  hierarchy  we  construct  an  order  over  the  regions  based  on  the  declarations.  (1)  We  extend 
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(Ec  and  Gc  to  relate  abstract  regions  to  classes.  (2)  We  assume  that  Object. Instance  g?  Object.  (3) 
We  define  new  relations  -<r  and  <r  over  all  regions;  c.rgn  -2  d .rgn'  only  when  rgn',  the  intended 
parent  region  of  rgn,  is  defined  in  class  c.  Predicate  WFRegions(P)  checks  that  the  regions  form 
a  hierarchy.  The  triple  rgn  A  d .rgn  looks  up  the  particular  region  with  name  rgn  that  is  defined 
in  class  c,  and  gives  its  fully  qualified  name.  Similarly,  rgn  <£c,  rgn'  compares  two  regions  based 
on  the  results  of  looking  up  the  region  names  in  classes  c  and  6.  To  check  that  the  regions  used  as 
superregions  are  defined  we  define  CompleteRegions(P).  We  update  NoShadowing(P)  to 
additionally  prevent  shadowing  of  abstract  regions. 

For  an  unshared  field  fd  in  class  c  that  references  an  object  of  class  d,  AggregationsOK(P) 
checks  that  the  associated  region  mapping  maps  regions  defined  in  6  to  abstract  regions  defined 
in  class  c.  Each  unshared  field  defines  a  function  M.jd  that  represents  its  aggregation  mapping. 
The  predicate  MapOK(P,  M,  c)  insures  that  this  mapping  respects  the  class  hierarchy  and  that 
every  region  of  the  uniquely  referenced  object  is  mapped  (perhaps  indirectly)  into  a  region  of  the 
referencing  object.  The  relations  (Ec  and  €c  as  applied  to  field  declarations  arc  updated  in  the 
obvious  and  tedious  manner  (not  shown). 

We  extend  the  type  signature  of  a  method  in  the  relation  £?  to  include  its  declared  effects;  the 
relation  £c,  not  shown,  is  also  updated  in  the  obvious  manner.  Predicate  MethodsOnce(P), 
also  not  shown,  is  updated  to  handle  the  extended  method  signature  as  well.  We  also  extend 
ClassMethodsOK(P)  so  that  method  overriding  preserves  declared  effects.  Parameter  names 
can  appear  in  declared  effects;  we  must  be  careful,  therefore,  in  how  we  compare  the  declared 
effects.  In  the  interest  of  simplicity,  we  deviate  from  the  original  definition  of  the  predicate  and  re¬ 
quire  that  method  overriding  preserve  parameter  names  so  that  the  declared  effects  may  be  directly 
compared.  For  simplicity,  we  also  require  that  overriding  methods  declare  exactly  the  same  effects. 
An  alternative  is  to  allow  the  declaration  of  more  specific  effects,  in  which  case  we  would  have  to 
check  that  all  the  effects  of  the  overriding  declaration  arc  accounted  for  in  the  original  declaration. 

fx 

The  new  relation  c  ip  maps  a  class  name  to  its  constructor  effects.  This  is  necessary  because 
FluidJava  does  not  have  formal  constructors;  if  it  did  we  would  treat  them  similarly  to  methods. 

fx 

We  assume  that  Object  i— >  reads  nothing  writes  nothing. 

For  the  full  Java  language,  we  also  have  to  check  that  no  static  region  is  a  subregion  of  an 
instance  region,  and  that  no  region  is  more  visible  than  its  parent  region. 
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Judgment 

Meaning 

F  P  :  tip 

P  F  defn 

P;  E  Fdeci  effect 

P-  E  Fdeci  tfft 

P;  E  F  effect 

P;  E  F  tgt 

P  F  t 

P,  c  F  field  !  p 

P,  c  F  meth 

P;  E  F  e  :  tip 

Program  P  yields  type  t  and  has  effect  p 

defn  is  a  well  formed  definition 

effect  is  a  well  formed  effect  declaration 

tgt  is  a  well  formed  target  within  an  effect  declaration 

effect  is  a  well  formed  effect 

tgt  is  a  well  formed  target 

t  exists 

field  is  a  well  formed  field  whose  initializer  has  effect  p 
meth  is  a  well  formed  method  in  type  c 

Expression  e  has  type  t  and  effect  p 

Figure  4.8:  Typing  judgments  for  the  extended  language. 

P  h  tgti  r  £p(lbl)  =  Ei ,  [final]opt  c  x,  Eg 

P  b  reads  tgt x  . . .  tgtj  writes  tgt^+1  . . .  tgtn  P  b  nothing  •  P  b  [x\im  • 

P;Sp(lbl)  b  e  :  cli/j  c' .rgn  Ec  c  c' .rgn  Ec  c 

P  b  [ej^.rpn  ^  c' .rgn  P  b  any(c).r^n  c'  .rgn 


Figure  4.9:  Rules  for  well  formed  effects  and  targets. 


4.11.2  Typing  Rules 

Typing  judgments  must  incorporate  effects,  and  now  have  the  forms  shown  in  Figure  4.8.  We 
now  have  rules  for  well  formed  effects  and  targets.  There  are  two  sets  of  rules,  one  that  limits  the 
shape  of  a  target  within  an  effects  declaration  clause,  and  a  second  set  for  general  effects  and  targets. 
Figure  4.9  shows  the  general  rules.  An  effect  is  well  formed  if  all  its  targets  arc  well  formed.  A  target 
is  well  formed  if  (1)  it  is  the  empty  target;  (2)  it  is  a  local  target  and  the  variable  is  defined  in  the 
environment;  (3)  it  is  an  instance  target  and  the  region  is  defined  in  the  type  of  the  expression;  or  (4) 
it  is  an  any-instance  target  and  the  region  is  defined  in  the  named  type.  Environments  are  determined 
from  the  label  of  the  expression  contained  within  the  target.  Well  formed  targets,  therefore,  must 
contain  labeled  expressions.  The  judgments  for  well  formed  instance  and  any-instance  targets  also 
elaborate  to  the  fully  qualified  name  of  the  region  that  is  named  in  the  target. 

The  rules  for  well  formed  effects  declarations  and  well  formed  targets  within  effect  declarations 
arc  shown  in  figure  4.10.  A  target  in  an  effects  declaration  must  be  the  empty  target,  an  instance 
target  whose  expression  is  a  method  parameter,  including  this,  or  an  any-instance  target.  The  limi- 
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P\  E  ^decl  tgti 

P\  E  ^decl  reads  tgt1  . . .  tgtj  writes  tgtj+1  . . .  tgtn 

E  =  Ei ,  [final]  t  c  x,  E%  c' .rgn  Ec  c 

P\  E  t~decl  x.rgn 


P\  E  hdeci  nothing 

c' .rgn  Ec  c 
P\  E  hdeci  any(c).rgn 


Figure  4.10:  Rules  for  well  formed  effect  declarations. 


Null  Abstract 

P  h  c  PH 

P;E  h  null  :  c  !  0  P;  E  h  abstract  :  i  !  0 


FinalVar 

E  =  E±,  final  t  x,  Eg 
P;Bhi:i!0 


Figure  4.11:  Rules  for  expressions  without  effects. 


tation  to  method  parameters  is  enforced  by  checking  the  well  formedness  of  the  effects  declaration 
in  an  environment  that  only  contains  method  parameters;  see  rule  Method  in  Figure  4.15.  Rule 
CLASS  checks  the  effects  of  the  constructor  using  an  environment  containing  this  only. 

We  discuss  the  program  type  and  effects  rules  bottom  up,  starting  with  effect-producing  expres¬ 
sions,  and  moving  upward  along  the  syntax  to  method  and  class  declarations.  Figure  4.11  gives 
the  rules  for  those  expressions  that  do  not  produce  or  propagate  any  effects.  Evaluating  the  null 
expression  does  not  produce  any  effects,  nor  does  evaluating  any  other  primitive  integer  or  boolean 
literal.  The  abstract  expression  has  no  effect — it  is  treated  like  an  empty  method  body.  Reading  a 
final  local  variable  produces  no  effect  because  such  a  variable  does  not  represent  mutable  state. 

The  rules  for  expressions  that  have  direct  effects  are  shown  in  Figure  4. 12.  These  are  the  expres¬ 
sions  that  cause  effects,  as  opposed  to  merely  propagating  the  effects  of  other  expressions.  Reading 
from  and  writing  to  a  non-final  local  variable  produce  read  and  write  effects,  respectively.  Reading 
from  a  non-final  field  causes  a  read  effect  to  the  field  and  propagates  the  effects  of  evaluating  the 


Var 

E  =  Ei ,  t  x,  E2 
P\E  h  [x]m  :  t !  (reads  [x]ibi} 

Get 

P,  E  h  [e]ibi  :  c\ip  (c'.fd,t)€cc 
P\E  h  [e]lbl.fd  :  t\ip  U  (reads  [e]lbl.fd} 


Assign 

P;  E  h  e  :  t !  t/j  E  =  Ei ,  t  x,  E2 
P;  E  [xjihi  m  e  :  t !  U  (writes  {x]lbi\ 

Set 

P-,E  h  [e]M  :  clip!  (c'.fd,  t)  Sc  c  P;  E  h  e'  :  *  !  -02 
P;  E  h  [e]ibi.fd  =  e'  :t !  in  U  ^2  U  (writes  [e]ibi.fd} 


Figure  4.12:  Rules  for  expressions  with  direct  effects. 
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New 

fx 

P  b  c  c  i— »  -0  NoAbstractMethods(P,  c) 

P;  P  h  new  c  :  c\i/j 

Invoke 

*1!) 

P]  E  \~  e  :  c  \  'tpe  P;  P  h  !  -0$  jmn,  • . .  tn  — >  t,  (xi  . . .  xn),  ej,)  Gc  c 

n 

en)  :  t !  ipe  U  (|^J  0*)  U  0  [e/th  is]  [e^/aii] 
i= l 

7p 

tn  — ►  t ,  (t;i  . . .  ?;n),  e^,)  Gc  c  e&  7^  abstract  P;  P  h  e*  :  !  -0* 

n 

P;E  h  super.  mn(ei  (!fcU  (|^J  ipi)  U  V’ler/'t'i] 

i=l 

Figure  4.13:  Rules  for  object  creation  and  method  calls. 


P;  E  \~  e.mn(e  1  . . . 

Super 

P;  E  b  this  :  c' !  i/jr  cr  ^(c  c  (mn,  t\  . . . 


expression  describing  the  receiver.  Similarly  for  assigning  to  a  field. 

The  rules  for  object  creation  and  method  calls  are  shown  in  Figure  4.13.  Constructing  an  object 

fx 

has  the  effects  declared  on  the  class,  obtained  using  the  i— >  relation.  If  we  had  named  construc¬ 
tors  in  our  language,  then  the  rule  would  be  similar  to  the  method  invocation  rule.  Invoking  a 
method  causes  the  latent  effects  'ip  of  the  method,  and  also  propagates  the  effects  of  evaluating  the 
expressions  for  the  receiver,  pje  and  the  method  arguments,  ript.  Any  parameter  names,  including  the 
receiver,  in  the  targets  of  the  method’s  effects  arc  simultaneously  replaced  by  the  actual  expressions. 
For  example,  if  method  Point .  add  ( Point  p)  has  the  effects 

{reads  this. Location,  reads  p. Location} 

then  the  expression  ptl .  add  (pt2 ) ,  has  the  effects 

reads  ptl,  pt2,  ptl. Location,  pt2. Location  writes  nothing 

The  rule  for  a  invoking  a  superclass  implementation  of  a  method  is  similar,  except  that  there  is  no 
substitution  for  this.  The  receiver  effect  is  always  {reads  this}  because  it  originates  from  a 
judgment  using  the  local  variable  this. 

Rules  for  the  rest  of  the  expressions  are  shown  in  Figure  4.14.  The  effects  of  all  these  expres¬ 
sions  are  simply  the  union  of  the  effects  of  their  subexpressions.  Reading  from  a  final  field  does 
not  produce  an  effect  on  that  field  because  it  is  not  considered  to  be  mutable  state.  Subsumption 
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FinalGet 

P;  E  b  e  :  c  !  -0  (c' .fd,  final  f)  £°  c 

P,Eb  e.fd:t\ip 

IF  SEQ 

P;  E  b  ej  :  boolean  !  i/>i  P;  E  h  eg  :  t !  1/12  P;  E  h  ej  :  f  !  ^3  P;  E  h  ej  :  f;  !  Vn  P;  P  h  eg  :  fg  !  i/>2 
P;Eh  if ( ej )  {eg}  else  { eg }  :  f  !  i/>i  U  ipi  U  ip3  P;  P  h  ei ;  eg  :  fg  !  ipl  U  ip2 


Let  Sub 

mod_t  =  [final]opt  t  x  g  E  P;  E  b  ej  :  f !  -i/’l  P\E,  mod_t  x  b  eg  :  t'  \ip2  P;Efe:c'!t/i  o'  <c  c 

P;Eh  let  mod_t  x  =  ej  in  {eg}  :  P !  ipi  U  t/>2  P\  E  b  e  :  c\ip 


Sync  Fork 

P;E  h  ej  :  cl^i  P,  E  b  eg  ■  t\ip2  P,  E  b  e  :  t\ij) 


P;Eh  synchronized(ej )  {eg}  :  t !  ip\  U  ip2  P;Eh  fork  {e}  :  int !  r/r 


Label 

P\  E  b  e  :  til/)  £PD{(lbl,E)} 


P-,Eb[e]m:t\il> 


Figure  4.14:  Rules  for  expressions  with  only  indirect  effects. 


is  not  allowed  to  widen  the  effects  of  the  expression.  Fork  is  interesting  because  it  does  not  have 
an  equivalent  expression  in  Java,  rather  it  corresponds  to  an  invocation  of  the  Thread,  start  ( ) 
method.  The  “body”  for  the  thread  is  defined  by  an  implementation  of  the  Runnable  interface’s 
run  ( )  method.  In  general,  this  means  the  effect  of  stalling  a  thread  in  Java  is  going  to  be  @writes 
Object .All. 

Finally,  the  rules  for  well  formed  definitions  and  programs  are  in  Figure  4.15.  The  predicate  an¬ 
tecedents  in  rule  PROG  arc  updated  as  previously  described.  There  is  an  additional  rule  for  unshared 
fields:  it  includes  the  previously  described  MapOK  predicate  as  an  antecedent.  The  rules  for  fields 
propagate  the  effect  of  field  initialization  expressions.  These  effects  are  gathered  in  the  CLASS  rule 
and  checked  against  the  declared  effects  of  the  class.  The  declared  effects  of  a  class  must  also  in¬ 
clude  the  effects  of  constructing  an  instance  of  its  superclass.  The  effects  of  the  body  of  a  method  arc 
checked  against  the  declared  effects  of  the  method.  Predicate  CheckFX(P,  args,  'ip.  ip),  where 
args  is  a  map  from  parameter  names  to  their  declared  types,  is  true  when  “all  the  effects  of  ip  arc 
included  in  the  effects  of  ip! .” 

4.11.3  Checking  Declared  Effects 

We  now  return  to  the  problem  of  checking  the  declared  effects  of  a  method  against  the  actual  effects 
of  the  method’s  implementation.  This  checking  is  abstractly  described  in  Section  4.3.3.  We  use 
an  “elaboration”  that  expands  a  set  of  effects  to  take  into  account  the  bindings  of  local  variables 
and  the  mapping  of  unshared  fields.  This  process  is  defined  in  Figure  4.16.  For  each  target  tgt 
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Prog 

ClassOnce(P)  RegionsOnce(P)  MethodsOnce(P)  NoShadowing(P)  CompleteClasses(P) 
WFClasses(P)  ClassMethodsOK(P)  UniqueLabels(P)  WFRegions(P) 
CompleteRegions(P)  AggregationsOK(P)  P  =  defn1  . . .  defnn  e  Ph  defni  P;  0  b  e  :  t !  ip 

h  P  :t\ip 


Class 

3 

CheckFX(P,  0,  mask(P,  elaborate(P,  ip  U  | _ J  i/'i) >  0),  effect) 

i=1  Field 

P;  final  cn  this  h<jeci  effect  P,  cn  h  field i !  ipi  P,  era  h  methi  c'  ip  P  \~  t  P;8h  e  :  i!t/i 


P  h  class  era  extends  c'  ■  ■  ■  effect  {■  •  ■  field1  . .  .fieldj  methi  . . .  meth j,} 


P,  c  b  [final] opt  t  fd  in  rgn  =  e  !  ip 


UnsharedField 

Phc'  P;0  h  e  :  o'  Up  MapOKfP,  Mcfd,  c') 

P,  c  h  unshared  [final]opt  c'  fd  in  rgn  aggregate  agg j  . . .  aggn  =  e\ip 


Method 

Phf  Ph  mod_ti  E  =  final  c  this,  mod_ti  xi,  ■  ■  ■ ,  mod_tn  xn  P\  E  e  :  t\ip  P\  E  hdeci  effect 
mod_ti  =  [final]opt  fi  CheckFX(P,  {this  i— >  c,  Xi  i— >  fi},  mask(P,  elaborate(P,  -0) ,  {this,  Si}),  effect) 

£P  D  {(Ibl,  E),  (, Ibh  ,  E), ,  (Ibln,  E)} 

P,  c  h  t  mnm(mod_t1  [xi . . .  mod_tn  [xn]ibln)  effect  {e} 


Figure  4.15:  Rules  for  well  formed  definitions  with  regions  and  effects,  elaborate,  mask,  and 
CheckFX  are  defined  in  Figures  4.16,  4.17,  and  4.18,  respectively. 


that  describes  a  region  of  an  object  referenced  by  a  local  variable,  (1)  binding  context  analysis  is 
used  to  find  the  possible  source  expressions  of  the  reference  and  (2)  new  targets — that  describe  the 
same  state  as  tgt — based  on  these  expressions  arc  added  to  the  set  of  targets.  The  purpose  of  this 
is  to  avoid  naming  state  through  local  variables  which  are  meaningless  outside  of  the  method  body. 
In  Java,  Binding  Context  Analysis  traces  the  source  of  a  local’s  value  to  (1)  a  method  parameter, 
(2)  a  new  expression,  (3)  a  method  call,  or  (4)  a  field  reference,  including  an  array  element.  As 
previously  discussed,  and  as  formalized  below,  effects  on  newly  created  objects  arc  ignored.  An 
instance  target  of  the  form  \x] ibi-rgn  where  x  binds  to  method  parameters  and  new  expressions  only 
can  be  accounted  for  by  declared  effects  on  regions  of  those  parameters.  This  is  our  implementation 
of  the  covers  relation  of  Section  4.3.3. 

Elaboration  also  exploits  the  mapping  of  unshared  fields.  In  general,  ignoring  labels,  targets  of 
the  form  e.fd.rgn  arc  replaced  by  targets  of  the  form  e. rgn!  when  fd  is  an  unshared  field  and  rgn  is  a 
subregion  of  a  region  that  maps  to  rgn'.  When  the  region  mapping  is  ambiguous,  because  two  related 
regions  arc  both  explicitly  mapped,  we  always  map  into  the  region  closest  to  the  leaves  of  the  region 
hierarchy.  In  combination  with  Binding  Context  Analysis  expanding  references  through  locals  into 
references  through  parameters  and  fields,  this  process  effectively  chases  a  chain  of  unique  object 
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map (P,  e.rgn,  M)  = 

min<r  { e.rgn  \  e.rgn  <r  c' .rgn'  A  M{c' .rgn')  =  e.rgn} 

]  elaborate(P,  reads  R  writes  IE)  =  reads  elaborate(P,  R)  writes  elaborate(P,  IE)  | 

elaborate(P,  T')  =  The  smallest  set  TDT'  su 
(  [x]m.rgn  £  T  =>  T  D  {e.rgn  e  € 

|  [[e] m-fd]ibi> .rgn'  £  T  =>  T  Z)  /[e];w.ryn 

ch  that 

B  [x)ibi  } 

P;£P(lbl)he:c\ip  j 

A  P-,£p(lbl,)b{e\m.fd:c,\4>'  ‘ 

A  rgn'  c' .rgn'  A  e.rgn  =  map(P,  c' .rgn,  AJ^)  J 

| 

Figure  4.16:  Effect  elaboration. 


unshared (P,  [e]m-fd)  = 

( P ;  £p(lbl )  h  e  :  c' !  ip)  A  fd  £->  c.fd  A  3c  :  class  c  ■  unshared  [final]opt  c  fd  ■  ■  ■}  is  in  P 

mask(P,  reads  7?  writes  IE,  arys)  =  reads  mask(P,  R,  args )  writes  mask(P,  IE,  arys) 
mask(P,  T,  arys)  =  {tgt  £  T  |  mask(P,  tgt,  args)} 

{true  ( tgt  =  [a:]u>f) 

x  £  args  ( tgt  =  [ x]wi-rgn ) 

true  [tgt  =  [new  c]ibi-rgn) 

unshared(P,  e.fd)  ( tgt  =  \e.fd\ibi.rgn) 

false  (Otherwise) 


Figure  4.17:  Effect  masking. 


references  to  the  “largest”  aggregation  visible  within  the  method  body.  Ideally  this  aggregation 
would  be  via  an  object  identifiable  through  a  method  parameter  (usually  this),  which  would  allow 
all  the  effects  on  the  aggregation  to  be  accounted  for  by  a  declared  effect  on  a  target  of  the  form 

x.rgn. 

Elaboration  is  followed  by  effect  masking,  defined  in  Figure  4.17,  which  in  addition  to  remov¬ 
ing  effects  based  on  the  criteria  described  in  Section  4.3.3,  also  removes  those  effects  rendered 
redundant  because  of  elaboration.8  More  specifically,  for  Fluid  Java, 

•  We  mask  effects  on  local  targets. 

•  We  mask  effects  on  instance  targets  x.rgn  where  x  is  not  a  method  parameter.  Such  effects 
are  redundant  after  elaboration  and  to  keep  them  would  require  the  declared  effects  to  use 
any-instance  targets. 

•  We  mask  effects  on  newly  created  objects. 

•  We  mask  effects  on  unshared  objects.  Such  effects  arc  redundant  after  elaboration,  which 
replaces  them  with  effects  on  an  aggregated  object. 

8We  cannot  remove  the  redundant  effects  during  elaboration  because  otherwise  it  is  not  possible  to  reach  a  fixed  point. 
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CheckFX(P,  args,  reads  P  writes  W,  reads  R'  writes  W') 

(' itgt  £  R  :  CheckTgt(P,  args,  tgt,  R'  U  W'))  A  (Vtgt  £  W  :  CheckTgt(P,  args,  tgt,  W')) 
CheckTgt(P,  args,  any (c).rgn,  T)  =  3any (c').rgn'  £  T  :  c  <°  d  A  rgn  <TC  c, ,  rgn' 
CheckTgt(P,  args,  x.rgn,  T)  = 

c  =  args(x)  A  (( 3x.rgn '  £  T  :  rgn  <ciG  rgn')  V  (3any  (c').rgn'  £T  :  c  <c  d  A  rgn  <^e/  rgn')) 
CheckTgt(P,  args,  [e] ibi.rgn,  T)  = 

_ 3any (c').rgn'  £  T  :  (P;  £p(lbl)  F  [e]wi  :  c !  i/i)  A  c  <c  c'  A  rgn  <Tc  ci  rgn' 


Figure  4.18:  Predicates  for  checking  implementation  effects  against  declared  effects. 


The  implementation  effects  of  a  method  arc  checked  against  the  method’s  declared  effects  by 
first  elaborating  them  and  masking  the  results.  Each  remaining  read  effect  must  be  accounted  for 
by  a  declared  read  or  write  effect;  each  remaining  write  effect  must  be  accounted  for  a  declared 
write  effect.  An  affected  any-instance  target  is  accounted  for  by  an  any-instance  target  identifying 
a  superregion  of  a  superclass.  An  instance  target  based  on  a  method  parameter  can  be  accounted 
for  by  a  target  identifying  a  superregion  of  the  same  parameter.  Otherwise,  in  general,  an  instance 
target  is  accounted  for  by  an  any-instance  target  identifying  a  superregion  of  a  superclass. 

4.11.4  Overlap  and  Conflict 

We  conclude  by  describing  how  to  compare  the  effects  of  two  expressions  to  determine  if  the  effects 
conflict.  That  is,  if  one  of  the  expressions  writes  something  that  the  other  one  reads  or  writes.  We 
start  by  defining  target  overlap  in  Figure  4.19:  we  say  two  targets  overlap  if  they  identify  state  that 
may  intersect.  Two  local  targets  overlap  if  they  refer  to  the  same  local  variable.  Two  non-local 
targets  overlap  only  if  they  can  refer  to  overlapping  regions  of  the  same  object,  where  two  regions 
overlap  if  one  is  a  subregion  of  the  other.  Two  instance  targets  can  overlap  only  if  the  objects  they 
refer  to  could  be  identical.  To  compare  instance  targets,  we  must  determine  whether  two  expressions 
from  different  points  in  the  program,  may  refer  to  overlapping  sets  of  locations.  This  observation 
has  led  us  to  formalize  the  desired  notion  of  equality,  based  on  the  context  of  the  expressions, 
as  a  new  alias  question  MayEqual([e\u,i,  {f-'}ihi)  [BG99],  More  traditional  alias  analyses,  such  as 
Steensgaard’s  “points-to”  analysis  [Ste96],  may  be  used  as  a  conservative  approximation. 

Two  well  formed  instance  targets  overlap  if  they  may  refer  to  overlapping  regions  of  the  the 
same  object.  A  well  formed  any-instance  target  may  refer  to  the  same  object  as  a  well  formed 
instance  target  if  the  type  of  the  object  that  the  instance  target  refers  to  has  a  subtype  that  is  also  a 
subtype  of  the  type  declared  in  the  any-instance  target.  That  is,  it  is  possible  that  the  object  referred 
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c.rgn  overlap1-  c' .rgn'  =  c.rgn  <r  c' .rgn'  V  c' .rgn'  <r  c.rgn 
P  h  tgi'  overlap*  tgt  P  h  [x]ibi  P  P  [x')Mi  x  =  x' 


P  h  tgt  overlap*  tgt1  P  h  [x]ibi  overlap*  [x']Mt 

P  b  [e\ibl-rgn^>  c.rgn  P  h  [e’]m>  .rgn  c'  .rgn'  MayEqual([e\ibi,  [e']iw) 

c.rgn  overlapr  c! .rgn' 

PP  [e] ibl-rgn  overlap*  [e']lhi> .rgn' 

P  b  [e] ibl-rgn  ^  c.rgn  P  b  any (c').rgn'  c! .rgn'  3t'  :  t'  <c  c  A  t'  <c  c' 

c.rgn  overlapr  c! .rgn' 

P  b  [e]n)i.rgn  overlap1  any(c/).r^n/ 

P  b  any (c).rgn  c.rgn  P  b  any (c').rgn'  ^  c! .rgn'  3t'  :  t'  <c  c  A  t'  <c  c' 

c.rgn  overlapr  c! .rgn' 

P  b  any (c).rgn  overlap1  any (c').rgn' 

Figure  4.19:  Rules  for  region  and  target  overlap. 

3t  G  T,  t'  £  T'  :  (P  b  t  overlapt  t')  P  b  elaborate(P,  R  U  W)  overlap11 

elaborate(P,  W') 

P  b  T  overlap11  T'  P  b  (reads  R  writes  W)  conflict  (reads  R'  writes  Wr) 

P  b  i//  conflict  P;Sp(lbl)  \~  [e]^  :  tlijj  P;  Sp(lbl')  b  [e']^/  :  t' !  i/i7  P  b  ijj  conflict  i/t/ 

P  \~  ip  conflict  i//  P  b  [e]ibi  interfere  [e7]^/ 

Figure  4.20:  Rules  for  conflict  and  interference.  We  abuse  notation  by  treating  elements  of  tgt, 
e.g.,  R  and  W ,  as  sets  of  targets. 


to  by  the  instance  target  is  included  in  the  class  of  objects  that  the  any-instance  target  may  refer  to. 
The  rule  for  two  any-instance  targets  is  similar. 

In  Figure  4.20,  we  extend  target  overlap  to  apply  to  a  set  of  targets.  Target  overlap  needs  to 
account  for  state  aggregation  from  the  mapping  of  regions  of  unshared  fields.  This  is  accomplished 
by  elaborating  the  sets  of  targets  before  comparing  them.9  Specifically,  two  effects  conflict  if  after 
elaborating  their  respective  targets,  one  of  them  writes  a  target  that  overlaps  with  a  target  read  or 
written  by  the  other.  Finally,  two  expressions  interfere  if  they  have  conflicting  effects. 


’Testing  for  overlap  this  way  is  overly  conservative.  Using  a  permissions-based  state  semantics  as  discussed  in 
Section  4.9  should  enable  the  use  of  a  less  conservative  and  more  intuitive  process  of  testing  for  overlap. 


Chapter  5 


Protecting  State 


A  fundamental  requirement  for  assuring  the  correct  use  of  shared  state  is  the  identification  of  what 
state  is  shared.  This  state  may  encompass  multiple  fields  of  an  object  and  even  span  multiple 
objects.  Chapter  4  describes  our  use  of  regions  to  identify  what  is  the  state  of  an  object  and  for 
aggregating  the  state  of  several  objects  into  a  single  named  abstraction  of  state.  Having  this  ground¬ 
work  to  name  state,  we  can  consider  protecting  portions  of  state  from  concurrent  access  by  using 
associations  of  locks  with  state  identified  by  hierarchical  regions  to  answer  how  is  access  to  state 
synchronized. 

Documenting  the  association  between  locks  and  specific  portions  of  state  is  not  a  new  idea.  The 
novelty  of  our  technique  is  the  association  of  locks  with  abstract  aggregations  of  state.  This  has 
important  benefits:  (1)  the  ability  to  describe  locks  that  protect  state  across  many  objects  and  (2) 
direct  support  for  subclassing  enabled  by  the  extensible  nature  of  regions.  Tool-supported  analyses 
based  on  documented  lock-related  design  intent  effectively  address  many  of  the  flaws  in  Java’s  im¬ 
plementation  of  the  monitor  concept;  see,  for  example,  [BH99b],  In  particular',  explicit  declaration 
of  shared  state  and  its  associated  lock  enables  the  assurance  of  correct  access  outside  of  the  class 
that  declares  the  state.  Associating  locks  with  hierarchical  regions  additionally  enables  program 
transformations  that  can  systematically  alter  the  granularity  of  data  protection  by  splitting  across 
subregions  (lock-splitting),  or  vice  versa  (lock- merging);  see  Chapter  8. 
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5.1  Associating  Locks  with  State 

Regions  arc  treated  like  Hoare’s  resources  [Hoa71]:  as  abstract  groups  of  shared  state.  The  pro¬ 
grammer  identities  a  shared  region  and  describes  how  it  is  to  be  protected  by  annotating  a  class 
with 

@lock  lockName  is  representation  protects  region 

This  declares  that  region  is  potentially  shared  and  thus  access  to  it  is  mediated  via  the  lock  ref¬ 
erenced  by  representation.  The  lock  is  known  by  the  abstract  name  lockName ,  hiding  the  lock’s 
representation  from  clients.  We  require  representation  to  be  either  this  or  a  final  field  we  select 
to  be  the  canonical  reference  to  our  lock  object.  Immutability  via  final  prevents  the  object  used  as 
the  lock  from  changing  during  the  lifetime  of  the  referring  object.  A  special  case  of  a  final  field 
is  the  Java  class  expression  C .  class,  where  C  is  a  class  name,  that  mimics  a  static  field  of  type 
Class  and  evaluates  to  the  Class  object  for  class  C. 

In  addition  to  the  requirement  that  the  representation  of  a  lock  be  final,  there  arc  several  other 
conditions  that  must  be  satisfied  for  the  declared  locking  model  to  be  well  formed;  these  arc  formally 
specified  in  Section  5.11.  The  representation  of  the  lock  that  protects  a  region  must  be  at  least  as 
visible  as  the  shared  region.  To  avoid  breaking  abstraction,  this  condition  may  be  met  by  declaring 
methods  that  return  references  to  locks;  see  Section  5.4.  No  region  may  be  associated  with  more 
than  one  lock.  Doing  so  enables  race  conditions  because  different  accesses  to  the  region  could  then 
acquire  different  locks  which  does  not  guarantee  mutually  exclusive  access  to  the  region.  This  rule 
has  several  immediate  implications  for  the  locking  model:  (1)  a  region  cannot  be  associated  with 
a  lock  if  it  has  an  ancestor  region  that  is  associated  with  a  lock;  and  (2)  a  static  region  must  be 
protected  by  a  static  field. 

5.1.1  Identifying  Locks 

We  distinguish  between  lock  names  and  lock  identifiers.  A  lock  name  is  declared  in  a  class  via  the 
@lock  annotation,  and,  for  instances,  declares  a  family  of  locks,  one  for  each  member  of  the  class. 
Thus,  the  lock  name  refers  to  a  particular  region  of  the  class.  Much  like  a  target  does  for  regions,  a 
lock  identifier  identifies  a  particular  lock  for  a  particular  instance.  A  lock  associated  with  a  static 
region  is  identified  by  the  lock  name  qualified  by  the  name  of  the  class  in  which  it  is  declared. 
A  lock  associated  with  an  instance,  i.e.,  non-static,  region  must  be  identified  with  respect  to  a 
particular  object.  An  instance  lock  is  thus  identified  by  the  pairing  of  an  object-valued  expression 
with  a  lock  name,  e.g.,  this  .  f  if  o .  Buf  Lock,  which  identifies  the  lock  named  BufLock  of  the 
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object  referenced  by  expression  this  .  f  if  o.  Instance  lock  identifiers  have  the  same  sort  of  aliasing 
problems  as  instance  targets. 

5.1.2  The  Locking  Model 

Lock  annotations  define  a  model  of  state  protection  for  the  class  that  is  enforced  by  static  analysis. 
In  particular,  any  field  that  is  a  member  of  the  region  must  be  accessed  only  from  within  a  critical 
section  holding  the  given  lock.  If  a  region  is  visible  in  a  subclass,  any  lock  requirement  associated 
with  it  is  binding  on  the  subclass.  The  obvious  caveat  is  that  the  representation  of  the  lock  must 
also  be  accessible.  Unprotected  accesses  to  state  that  is  part  of  this  model  are  revealed  as  inconsis¬ 
tencies  between  the  stated  design  intent  and  source  code.  It  is  unfortunately  not  possible  to  detect 
shared  usage  of  state  not  intended  to  be  shared  without  additional  knowledge  about  the  existence  of 
threads.  This  is  also  true  for  similar  tools  and  analyses,  e.g.,  RaceFreeJava  and  ESC/Java.  We 
are  currently  developing  “thread  coloring”  annotations  for  thread  identification  that,  among  other 
uses,  can  address  this  problem  [SGS02]. 

Fields  that  arc  declared  to  be  immutable,  final  in  Java,  arc  exempt  from  the  declared  locking 
model.  Even  if  a  final  field  is  a  subregion  of  a  protected  region,  no  lock  needs  to  be  held  before 
accessing  the  field.  Fields  declared  to  be  volatile  arc  also  exempt  from  the  declared  locking 
model  because  volatility  expresses  the  intent  that  the  value  of  the  field  can  change  unpredictably 
(because  it  is  not  in  the  thread’s  local  memory)  and  thus  it  cannot  participate  in  an  invariant  with 
another  field.  Of  course,  objects  referenced  through  final  and  volatile  fields  arc  not  exempt 
from  the  locking  model  that  might  be  associated  with  their  type. 


5.2  Example:  Class  BoundedFiFO 

We  return  to  the  class  BoundedFiFO  from  Log4j.  Previously,  in  Chapter  4,  we  annotated  the 
class  with  regions  and  effects;  the  results  arc  shown  in  Figure  5.1.  As  a  reminder,  the  class  is  used 
to  pass  LoggingEvent  objects  between  two  threads.  Clients  executing  in  different  threads  must 
follow  an  undocumented  convention  during  concurrent  use  to  assure  atomic  access  to  the  FIFO.  For 
example,  two  concurrent  executions  of  put  could  result  in  the  loss  of  an  event,  because  the  two 
different  events  could  be  written  to  the  same  buf  location. 

The  synchronization  convention  is  that  access  to  a  BoundedFiFO  instance  must  be  coordinated 
by  clients  synchronizing  on  the  instance.  Typical  usage  requires  a  critical  section  within  the  client 
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1  /** 

2  *  @methodSet  readers  =  getMaxSize,  length,  wasEmpty,  wasFull, 

3  *  @set  readers  reads  Instance 

4  */ 

5  public  class  BoundedFIFO  { 

6  /**  @unshared 

7  *  ©aggregate  Instance  into  Instance  */ 

8  LoggingEvent []  buf; 

9  int  numElts  =  0,  first  =  0,  next  =  0,  size; 

10 

11  /**  Create  a  new  buffer  of  the  given  capacity. 

12  *  @writes  nothing  */ 

13  public  BoundedFIFO (int  size)  { 

14  if (size  <  1)  throw  new  IllegalArgumentException ( ) ; 

15  this,  size  =  size; 

16  buf  =  new  LoggingEvent [size] ; 

n  } 

18 

19  /**  Returns  <code>null</code>  if  empty. 

20  *  @writes  Instance  */ 

21  public  LoggingEvent  get ( )  { 

22  if (numElts  ==  0)  return  null; 

23  LoggingEvent  r  =  buf  [first]  ; 

24  if(++first  ==  size)  first  =  0; 

25  numElts--; 

26  return  r; 

27  } 

28 

29  /**  If  full,  then  the  event  is  silently  dropped. 

30  *  @writes  Instance  */ 

31  public  void  put (LoggingEvent  o)  { 

32  if  (numElts  !=  size)  { 

33  buf  [next]  =  o; 

34  if  (++next  ==  size)  next  =  0; 

35  numElts++; 


38 

39  /**  Get  the  capacity  of  the  buffer.  */ 

40  public  int  getMaxSize ()  {  return  size;  } 

41 

42  /**  Get  the  number  of  elements  in  the  buffer.  */ 

43  public  int  length ()  {  return  numElts;  } 

44 

45  /**  Returns  <code>true</code>  if  the  buffer  was  empty 

46  *  before  last  put  operation.  */ 

47  public  boolean  wasEmpty  ( )  { 

48  return  numElts  ==  1; 

49  } 

50 

51  /**  Returns  <code>true</code>  if  the  buffer  was  full 

52  *  before  the  last  get  operation.  */ 

53  public  boolean  wasFullO  {  return  numElts+1  ==  size;  } 

54 

55  /**  Is  the  buffer  full?  */ 

56  public  boolean  isFullO  {  return  numElts  ==  size;  } 

57  } 


isFull 


Figure  5.1:  Class  BoundedFIFO  with  region  and  effect  annotations. 
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public  class  PutterClient  {  ... 
private  final  BoundedFIFO  fifo; 

public  PutterClient (BoundedFIFO  bf,  ...)  {  fifo  =  bf;  ...  } 

public  void  putter (LoggingEvent  e)  { 
synchronized ( fifo)  { 
while ( fifo . isFull () )  { 

try  {  fifo.waitO;  }  catch  (InterruptedException  ie)  {  } 

} 

f if o . put (e) ; 

if ( f if o . wasEmpty ( ) )  f if o . notify ( ) ; 


public  class  GetterClient  {  ... 
private  final  BoundedFIFO  fifo; 

public  GetterClient (BoundedFIFO  bf,  ...)  {  fifo  =  bf;  ...  } 

public  LoggingEvent  getter ()  { 
synchronized ( fifo)  { 

LoggingEvent  e ; 

while ( fifo . length ( )  ==  0)  { 

try  {  fifo.waitO;  }  catch  ( InterruptedException  ie)  {  } 
e  =  fifo . get ( ) ; 

if ( f if o . wasFull ( ) )  f if o . notify ( ) ; 
return  e; 


Figure  5.2:  Canonical  clients  for  BoundedFIFO. 


spanning  a  series  of  calls  to  a  BoundedFIFO.  Figure  5.2  reorganizes  BoundedFIFO  client  code 
from  Log4j  into  canonical  producer  and  consumer  clients.  Our  use  of  lock-related  annotations  in 
this  chapter  make  explicit:  (1)  the  delineation  of  the  shared  state  of  an  abstract  BoundedFIFO,  (2) 
the  locking  conventions  for  safely  accessing  the  state,  and  (3)  the  placement  of  responsibility  to 
acquire  locks. 

The  region  annotations  in  BoundedFIFO  make  explicit  the  design  intent  that  each  instance  of 
the  class  has  a  unique  private  array  that  is  treated  as  if  it  were  paid  of  the  FIFO  instance.  We  now 
wish  to  annotate  the  additional  intent  that  the  state  of  a  FIFO  instance  is  to  be  protected  by  the 
locking  on  the  instance  itself.  This  is  done  by  annotating  the  class  with 

@lock  BufLock  is  this  protects  Instance 

The  implementation  of  BoundedFIFO  does  not  actually  acquire  this  newly  declared  lock;  we  ad¬ 
dress  this  issue  in  Section  5.4.2. 


86 


CHAPTER  5.  PROTECTING  STATE 


5.3  Example:  Class  ThreadCache 

We  can  easily  document  the  locking  design  intent  of  in  the  classes  ThreadCache  and  Cached - 
Thread  from  the  Jigsaw  web  server.  The  classes  with  region  and  locking  annotations  arc  shown 
in  Figure  5.3.  What  is  potentially  surprising  to  the  reader  of  this  code  is  that  part  of  the  state  of 
a  CachedThread  object  is  protected  by  the  thread  object  itself,  but  other  parts  of  the  thread’s 
state  are  protected  by  a  distinguished  ThreadCache  object.  The  region  structure  developed  in 
Section  4.7  helps  to  describe  the  locking  intent.  Recall  that  the  class  CachedThread  is  param¬ 
eterized  by  a  region  that  is  used  as  the  parent  region  of  the  next  and  prev  fields.  As  a  result, 
the  “backbone”  of  the  linked  list  assembled  by  a  ThreadCache  object,  made  up  of  its  freelist 
and  f  reetail  fields,  and  the  next  and  prev  fields  of  CachedThread  objects,  resides  entirely  in 
cache’s  Threads  region. 

The  lock  annotation  on  line  12  documents  the  intent  that  ThreadCache  objects  use  themselves 
as  the  lock  to  protect  their  Instance  region.  In  this  case,  the  Threads  region  is  a  subregion  of 
Instance  and,  as  discussed  above,  spans  multiple  objects.  This  annotation,  in  combination  with 
state  aggregation  documented  by  the  region  annotations,  captures  the  design  intent  that  the  next 
and  prev  fields  are  protected  by  the  ThreadCache  object  that  manages  the  CachedThread  object 
of  which  they  arc  a  paid.  The  annotation  on  line  44  documents  the  intent  that  the  rest  of  the  state 
of  a  thread  object  is  protected  by  the  thread  itself.  In  particular,  the  region  it  associates  with  a  lock, 
Threadlnf  o,  does  not  contain  the  next  and  prev  fields. 

Explicating  the  design  intent  regarding  the  shared  state  of  CachedThread  and  ThreadCache 
objects  makes  it  less  likely  that  a  future  maintainer  will  assume  that  the  next  and  prev  fields  arc 
protected  by  their  respective  thread  object.  Static  analysis  provides  the  additional  assurance  that  the 
implementation  does  not  deviate  from  the  locking  model.  For  example,  analysis  assures  that  method 
isFree  ( )  correctly  accesses  state  the  state  of  the  linked  list  backbone.  Both  parameter  t  and  field 
f  reetail  are  declared  to  have  the  annotated  type  CachedThreadcthis  .  Threads >.  The  field 
references  t.prev  and  f  reetail .  next  are  thus,  transitively,  accesses  to  the  region  Instance 
of  the  method’s  receiver,  and  correctly  protected  because  of  the  synchronized  modifier  on  the 
method;  see  line  20. 
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1  /** 

2  *  @region  public  Threads 

3  *  @region  public  Cachelnfo 

4  */ 

5  public  class  ThreadCache  { 

6  /**  @mapInto  Cachelnfo  */ 

7  protected  int  threadcount,  usedthreads; 

8  //  [code  omitted] 

9  /**  @mapInto  Threads  */ 

10  protected  CachedThread  /*@<this . Threads>*/  freelist,  freetail; 

11 

12  /**  @lock  CacheLock  is  this  protects  Instance  */ 

13 

14  private  synchronized 

15  CachedThread  /*@<this . Threads>*/  createThread ( )  {  ... 

16  return  new  CachedThread  /*@<this . Threads>*/  (this,...); 

17  } 

18 

19  /**  @writes  t . Threadlnf o,  this . Instance  */ 

20  synchronized  boolean 

21  isFree (CachedThread  /*@<this . Threads>*/  t,  ...)  { 

22  if  (  !  t .  isTerminated  ( )  )  {  .  ..  } 

23  else  {  ... 

24  t.prev  =  freetail; 

25  if (freetail  !=  null)  freetail . next  =  t; 

26  freetail  =  t; 

27  if (freelist  ==  null)  freelist  =  t; 

28  usedthreads--;  ... 

29  }  .  .  . 

30  }  //  [rest  of  class  omitted] 

31  } 

32 

33  /**  @region  public  Threadlnfo  */ 

34  class  CachedThread  /*@<region  Backbone>*/  extends  Thread  { 

35  private  final  ThreadCache  cache; 

36  /**  @mapInto  Threadlnfo  */ 

37  private  boolean  alive; 

38  /**  @mapInto  Threadlnfo  */ 

39  private  Runnable  runner; 

40  //  [code  omitted] 

41  /**  @mapInto  Backbone  */ 

42  CachedThread  /*@<Backbone>*/  next,  prev; 

43 

44  /**  @lock  ThreadLock  is  this  protects  Threadlnfo  */ 

45 

46  /**  @writes  Threadlnfo  */ 

47  synchronized  boolean  isTerminated ( )  {  ...  } 

48 

49  //  [Additional  synchronized  methods  follow] 

50  } 


Figure  5.3:  Classes  ThreadCache  and  CachedThread  with  lock  annotations:  lines  12  and  44. 
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5.4  Lock  Usage  Annotations 

A  method  is  usually  assumed  to  be  responsible  for  introducing  the  critical  sections  necessary  for 
any  shared  state  that  it  accesses.  This  common  Java  assumption  is  often  relaxed  when  a  private 
method  assumes  its  callers  already  hold  locks.  This  is  useful  when  the  method  is  likely  to  be 
commonly  invoked  in  contexts  where  the  necessary  locks  arc  already  held.  The  Javadoc  for  the  copy 
method  in  class  j  ava .  lang .  stringBuf  f  er,  for  example,  states  “[This  method]  should  only  be 
called  from  a  synchronized  method.”  The  Java  assertion  mechanism  includes  the  ability  to  test 
whether  a  thread  holds  a  particular  lock  [BloOlb];  we  encounter  an  example  of  this  in  Section  7.6. 
These  arc  informal  annotations  of  design  intent:  the  former  is  not  assurable  by  a  analysis;  the  latter 
is  not  statically  assurable,  rather  it  results  in  a  runtime  exception  when  violated. 

To  enable  static  assurance  of  such  methods,  we  use  a  formal  annotation  that  answers  the  question 
which  locks  must  be  held  before  a  method  may  be  invoked.  The  same  information  also  answers  the 
converse:  what  locks  are  assumed  to  be  held  when  this  method  is  invoked.  We  refer  to  this  design 
intent  as  “locking  preconditions,”  and  record  it  using  an  annotation  on  methods: 

@requiresLock  lockName\  ,  ...  ,  lockNamen 

This  annotation  defines  an  analysis  cutpoint.  When  assuring  an  implementation  of  the  method, 
analysis  can  assume  that  the  named  locks  arc  held.  The  validity  of  this  assumption  is  preserved  by 
assuring  that  each  invocation  of  the  method  occurs  in  a  context  where  the  named  locks  are  in  fact 
held.  To  preserve  modular  reasoning,  the  locking  precondition  of  a  method  is  not  allowed  to  be 
extended  by  a  reimplementation  of  the  method. 

Locking  preconditions  arc  in  terms  of  locks  of  the  receiver  or  static  locks.  It  is  not  presently  al¬ 
lowed  to  name  locks  of  other  objects  as  preconditions,  but  an  obvious  and  straightforward  extension 
is  to  allow  the  naming  of  locks  of  parameters. 

In  addition  to  requiring  locks,  a  method  can  also  result  in  a  lock.  Because  locks  arc  objects  in 
their  own  right,  references  to  objects  used  as  locks  can  be  method  return  values.  This  occurs  in  the 
Java  Abstract  Window  Toolkit  (AWT)  implementation,  for  example:  class  j  ava .  awt .  Component 
has  a  method  getTreeLock.  This  method  “Gets  this  component’s  locking  object  (the  object  that 
owns  the  thread  synchronization  monitor)  for  AWT  component-tree  and  layout  operations.”  Meth¬ 
ods  that  return  locks  arc  useful  for  hiding  the  exact  representation  of  a  lock  from  clients.  By  using  a 
method  that  is  declared  to  return  a  specific  lock,  the  field  that  actually  refers  to  that  lock  can  be  kept 
private  to  the  implementation  of  the  class.  Exposing  a  lock  by  increasing  the  visibility  of  the  field 
that  refers  to  it  violates  more  than  just  the  standard  principles  of  encapsulation  as  applied  to  locking 
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concerns.  Because  it  is  often  the  case  that  the  object  used  as  a  lock  is  also  used  to  implement  other 
functionality  within  the  class,  requiring  the  lock  reference  to  be  exposed  would  thus  require  data 
abstraction  principles  to  be  violated  in  the  service  of  obtaining  assurance  about  lock-related  design 
intent. 

The  design  intent  that  a  method  returns  a  particular  lock  of  the  receiver  is  recorded  using  the 
annotation 

@returnsLock  lockName 

The  return  value  from  such  a  method  can  be  used  in  contexts  where  the  lock  lockName  is  expected; 
Section  5.6  discusses  this  in  more  detail.  A  method  with  a  @requiresLock  annotation  must  be 
assured  to  return  the  named  lock. 

5.4.1  Methods  wait  and  notify 

An  interesting  case  of  method  preconditions  arc  the  methods  wait  and  notify,  and  their  kin,  in 
java.  lang. Object.  These  methods  are  used  to  implement  a  condition  variable.  As  such,  they 
require  that  the  lock  for  the  object  is  held  before  they  arc  invoked;  an  exception  is  thrown  at  run¬ 
time  if  the  lock  is  not  held.  We  use  our  @requiresLock  annotation  to  assure  statically  that  the 
appropriate  lock  is  held  when  they  arc  invoked.  In  particular-,  we  annotate  the  class  Object1  to 
introduce  a  new  public  region  WaitQueue  and  associate  the  lock  represented  by  the  receiver  with 
the  region: 

@region  public  WaitQueue  extends  All 
@lock  MUTEX  is  this  protects  WaitQueue 

Methods  wait,  wait  (long) ,  wait  (long,  int) ,  notify,  and  notifyAll  are  all  annotated  with 
the  lock  precondition 

@requiresLock  MUTEX 


5.4.2  Class  BoundedFiFO  Revisited 

For  an  instance  of  BoundedFiFO,  (1)  the  instance  itself  is  locked  to  protect  its  state  and  (2)  clients  of 
the  FIFO  instance,  rather  than  the  FIFO’s  methods,  are  expected  to  acquire  that  lock.  In  Section  5.2 

'The  mechanism  used  for  annotating  preexisting  library  code  is  described  in  Section  7.3. 
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we  showed  how  to  document  the  design  intent  for  (1).  We  now  document  the  design  intent  for  (2). 
That  this  is  the  intent  is  supported  by  the  observations 

•  None  of  the  methods  in  BoundedFIFO  are  synchronized 

•  The  clients  shown  in  Figure  5.2  synchronize  on  the  FIFO  object  before  invoking  any  of  its 
methods. 

We  record  this  design  intent  by  annotating  each  method  of  BoundedFIFO  with  the  locking  precon¬ 
dition 

@requiresLock  BufLock 

Figure  5.4  shows  a  fully  annotated  BoundedFIFO  implementation. 

Without  this  annotation,  an  analysis  local  to  BoundedFIFO  would  warn  of  potential  race  condi¬ 
tions  because  the  method  implementations  do  not  acquire  the  appropriate  locks,  and  there  would  be 
no  way  to  guarantee  that  all  the  call  sites  follow  the  locking  convention.  With  the  annotation,  assur¬ 
ance  of  the  implementation  of  BoundedFlFO’s  methods  succeeds  because  each  method  is  analyzed 
under  the  assumption  that  the  lock  BufLock  is  held.  Assurance  of  the  clients  succeeds  because 
the  block  synchronized (fifo)  {  .  .  .  }  can  be  determined  to  acquire  the  lock  fifo. BufLock 
necessary  to  satisfy  the  preconditions  of  the  methods  invoked  within  the  block.  Analysis  is  also 
able  to  assure  that  the  precondition  of  wait  and  notify,  the  lock  fifo  .MUTEX,  is  satisfied  by  the 
client  code.  The  same  synchronized  blocks  that  satisfy  the  preconditions  for  the  BoundedFIFO 
methods  also  satisfy  the  preconditions  for  the  condition  variable  because  the  reference  fifo  also 
represents  the  lock  f  if  o .  MUTEX. 

Occasionally  it  is  necessary  to  reorganize  code  in  the  service  of  annotation.  For  example,  if  the 
implementors  of  BoundedFIFO  do  not  wish  to  reveal  to  clients  of  the  class  that  BufLock  is  this, 
perhaps  because  they  do  not  want  to  be  committed  to  using  this  representation  in  the  future,  they 
could  introduce  a  new  method  into  BoundedFIFO: 

/**  @returnsLock  BufLock  */ 

public  Object  getLockO  {  returns  this;  } 

Clients  would  then  use  getLock  instead  of  fifo  when  synchronizing  access  to  the  buffer;  e.g., 
synchronized (fifo . getLock ( ) )  { . . . } 

By  better  encapsulating  the  representation  of  BufLock,  this  approach  makes  it  easier  to  change 
the  representation  of  BufLock  in  the  future.  Without  this  encapsulation,  all  uses  of  BoundedFIFO 
instances  would  have  to  be  found  and  the  lock  that  clients  acquire  altered  to  conform  to  the  new 
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representation.  This  is  clearly  a  non-local  modification,  especially  if  BoundedFlFO  were  paid  of 
a  library.  With  this  encapsulation  however,  just  a  local  change  to  getLock — and  its  associated 
assurance — is  required. 

As  a  caveat  to  the  above,  we  remark  that  in  the  case  of  locks  represented  by  this,  the  use 
of  lock-returning  methods  cannot  be  enforced  by  visibility  constraints  on  the  lock  representation 
because  the  receiver  for  a  method  is  always  available  to  the  caller.  In  the  case  of  locks  represented 
by  fields  of  a  class,  the  field  can  be  made  private  to  the  implementation  and  thus  the  clients  will 
have  to  use  the  method  to  get  a  reference  to  the  lock  because  the  standard  language  semantics  will 
prevent  the  clients  from  referencing  the  private  field.  An  appealing  general  solution  to  this  problem 
is  to  require  that  locks  be  obtained  from  method  calls  only,  but  this  may  lead  to  an  awkward  coding 
style,  or  at  least  one  that  is  not  commensurate  with  current  Java  coding  practices.  We  thus  opt  not 
to  impose  this  requirement. 


5.5  Shared  State  and  Obj'ect  Construction 

When  an  object  is  constructed  it  is  responsible  for  initializing  the  values  of  its  fields.  The  @lock 
annotation  associates  locks  with  subsets  of  fields,  via  regions,  that  must  be  held  before  those  fields 
arc  read  or  written,  and  these  ought  to  apply  to  the  field  assignments  performed  during  object  con¬ 
struction.  Common  programming  practice  in  Java,  however,  is  to  not  acquire  locks  in  the  imple¬ 
mentation  of  constructors.  In  fact,  while  the  Java  language  allows  a  method  to  be  declared  to  be 
synchronized,  it  is  illegal  to  declare  a  constructor  to  be  synchronized.  The  actions  of  a  con¬ 
structor  arc  allowed  to  be  fully  general,  however,  and  thus  there  is  no  general  rationale  for  excusing 
constructors  from  complying  with  accepted  thread-safe  programming  practices.  What  explains  this 
seeming  contradiction  between  recommendation  and  practice? 

A  better  question  is  under  what  circumstances  might  an  object  in  the  process  of  being  con¬ 
structed  be  accessed  by  multiple  threads?  This  can  only  happen  if  a  reference  to  the  newly  created 
object,  the  object  referenced  by  this  in  the  implementation  of  the  constructor,  is  given  to  another 
thread  during  the  process  of  construction.  Truly,  it  is  an  unusual  constructor  that  allows  this  to 
happen.  Thus,  if  the  constructor  does  not  leak  a  reference  to  the  object  to  another  thread,  it  is 
impossible  for  the  object  to  be  concurrently  accessed  during  construction.  It  is  thus  beneficial  to 
document  explicitly  the  intent  that  the  constructor  does  not  leak  the  newly  constructed  object  to  any 
other  threads.  We  use  the  annotation 
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on  constructors  for  this  purpose.  This  annotation  is  a  misnomer  because  the  constructor  does  not 
acquire  locks  as  a  result  of  the  annotation,  but  is  meant  to  be  evocative  of  synchronized  methods 
and  to  address  the  common  complaint  of  inexperienced  Java  programmers  that  constructors  cannot 
be  synchronized. 

When  a  constructor  so  annotated  is  analyzed,  it  is  assumed  that  all  the  programmer-declared 
locks  associated  with  instance  regions  of  the  class  arc  held.  Specifically,  the  lock  MUTEX  defined 
in  Object  is  not  assumed  to  be  held  because  this  would  incorrectly  allow  the  wait  and  notify 
methods  to  be  invoked  outside  of  a  critical  section.  Locks  protecting  static  regions  arc  not  as¬ 
sumed  to  be  held  because  static  state  exists  independently  of  any  instances  and  can  thus  already 
have  references  to  it  from  other  threads.  It  remains  for  analysis  to  assure  that  the  newly  constructed 
object  is  not  leaked  to  any  other  threads.  Our  implementation  of  this  analysis  is  overly  conservative. 
For  a  ©synchronized  constructor,  analysis  verifies  that  the  receiver  is  declared  to  be  ©borrowed, 
that  is,  that  no  aliases  to  the  receiver  survive  when  the  constructor  returns  to  its  caller.  Assurance 
that  the  receiver  is  actually  borrowed  is  performed  by  the  same  analysis  that  assures  the  correct  use 
of  unshared  fields  [BoyOla],  and  is  beyond  the  scope  of  this  work.  This  analysis  is  overly  conserva¬ 
tive  because  it  does  not  consider  at  all  the  question  of  whether  the  surviving  aliases  arc  from  other 
threads.  This  particular  means  of  assurance  is  simply  a  convenient  implementation  choice,  however, 
and  more  discerning  analyses,  such  as  those  of  [Bla99,  BH99a,  CGS1  99.  WR99]  could  be  used  to 
assure  the  ©synchronized  annotation. 

We  observe  that  short  of  using  a  lock  external  to  the  object  being  created,  and  acquired  prior  to 
invocation  of  the  constructor,  it  is  impossible  to  guarantee  that  an  object  will  be  constructed  within 
a  single  critical  section.  This  is  because  attempting  to  synchronize  a  constructor  by  enclosing  its 
body  within  a  synchronized  block  fails  to  capture  the  mandatory  invocation  of  a  constructor  of 
the  superclass.  Thus  the  best  that  can  be  achieved  by  synchronizing  the  body  of  a  constructor  is 
construction  across  multiple  critical  sections,  which  still  allows  the  possibility  of  another  thread 
accessing  the  object  in  between  constructors. 

5.5.1  Constructing  BoundedFIFO 

As  an  example,  consider  the  constructor  of  class  BoundedFIFO.  The  fields  size  and  buf  arc 
initialized  by  the  constructor,  and  analysis  to  assure  consistency  with  the  stated  locking  model  will 
fail  to  assure  the  constructor  because  it  does  not  acquire  this.  The  constructor  cannot  pass  the 
responsibility  to  its  callers  via  a  @requiresLock  annotation:  the  caller  cannot  have  a  reference  to 
the  required  lock — i.e.,  the  object  being  created — because  it  does  not  yet  exist  at  the  point  where  it 
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must  be  acquired.  (Constructors  can  require  as  a  precondition  the  acquisition  of  static  locks.)  It 
is  obvious  that  it  is  impossible  for  the  BoundedFlFO  object  to  be  shared  while  being  constructed — 
the  object  is  clearly  thread-local  during  construction.  We  thus  document  the  design  intent  that  the 
constructor  does  not  allow  the  receiver  to  escape  to  another  thread,  and  add  the  supporting  aliasing 
annotation;  the  results  arc  in  Figure  5.4. 


5.6  Identifying  Locks 

The  primary  analysis  problems  for  assuring  the  correct  use  of  shared  state  are  (1)  identifying  the 
portion  of  shared  state  that  is  being  accessed,  and  therefore  the  lock  that  is  required  to  access  it, 
and  (2)  identifying  the  locks  that  are  acquired  by  synchronized  statements  and  methods.  The 
first  problem  is  addressed  by  the  programmer-declared  regions  of  state  and  programmer-declared 
lock-region  associations.  Shared  state  is  accessed  via  field  references  and  indexing  into  arrays. 
The  region  hierarchy  as  modified  by  uniqueness  and  parameterization  aggregations  is  consulted  to 
determine  if  an  ancestor  region  of  the  field  is  associated  with  a  lock.  If  such  an  ancestor  region 
exists,  then  that  region’s  associated  lock  is  required  to  access  the  field.  For  example,  consider  the 
expression  this  .  buf  [this  .  first]  in  the  get  method  of  BoundedFlFO.  The  field  first  is  a 
subregion  of  the  receiver’s  Instance  region,  which  is  associated  with  the  lock  named  Buf  Lock 
represented  by  this.  The  array  access  this  .buf  [ .  .  .  ]  also  accesses  the  region  Instance  of 
the  receiver  because  of  uniqueness  aggregation.  Thus  the  lock  required  by  both  accesses  is  the  lock 
identified  by  this  .  Buf  Lock.  The  process  of  identifying  which  lock  is  required  for  a  particular 
field  access  is  formally  described  in  Section  5.11. 

To  determine  which  lock  is  acquired  by  a  synchronized  block,  an  object- valued  expression 
must  be  converted  into  the  set  of  locks  that  it  can  represent.  A  single  expression  can  simultaneously 
represent  locks  for  different  regions  of  the  same  object  because  the  same  representation  can  be 
used  for  many  different  locks  within  a  class.  A  field  reference  e .  f,  where  f  is  non-static,  can 
additionally  represent  locks  for  two  different  objects:  (1)  the  locks  represented  by  the  field  f  of  the 
object  referenced  by  e,  and  (2)  the  locks  represented  by  this  of  the  object  referenced  by  e .  f.  For 
a  lock  expression  e  (where  e  may  in  turn  be  a  field  reference  expression),  the  type  of  e  is  checked 
to  determine  the  lock  names,  if  any,  whose  representation  is  this;  for  each  such  lock  name  /,  the 
lock  identifier  e  .1  is  added  to  the  set  of  locks.  For  a  field  reference  e .  f ,  the  type  of  e  is  consulted 
to  determine  the  lock  names,  if  any,  whose  representation  is  the  field  f .  If  f  is  static,  then  the 
trivially  constructed  lock  identifiers  arc  added  to  the  set  of  possible  locks;  otherwise,  for  each  such 
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1  /** 

2  *  @methodSet  readers  =  getMaxSize,  length,  wasEmpty,  wasFull, 

3  *  @methodSet  calleeLocked  =  get,  put,  readers 

4  *  @lock  BufLock  is  this  protects  Instance 

5  *  @set  readers  reads  Instance 

6  *  @set  calleeLocked  requiresLock  BufLock  */ 

7  public  class  BoundedFIFO  { 

8  /**  @unshared 

9  *  ©aggregate  Instance  into  Instance  */ 

10  LoggingEvent  []  buf; 

11  int  numElts  =  0,  first  =  0,  next  =  0,  size; 

12 

13  /**  Create  a  new  buffer  of  the  given  capacity. 

14  *  @writes  nothing 

15  *  (©borrowed  this 

16  *  ©synchronized  */ 

17  public  BoundedFIFO  ( int  size)  { 

18  if (size  <  1)  throw  new  IllegalArgumentException ( ) ; 

19  this,  size  =  size; 

20  buf  =  new  LoggingEvent [size] ; 

21  } 

22 

23  /**  Returns  <code>null</code>  if  empty. 

24  *  @writes  Instance  */ 

25  public  LoggingEvent  get  ( )  { 

26  if  (numElts  ==  0)  return  null; 

27  LoggingEvent  r  =  buf  [first]  ; 

28  if(++first  ==  size)  first  =  0; 

29  numElts--; 

30  return  r; 

31  } 

32 

33  /**  If  full,  then  the  event  is  silently  dropped. 

34  *  @writes  Instance  */ 

35  public  void  put (LoggingEvent  o)  { 

36  if  (numElts  !=  size)  { 

37  buf  [next]  =  o; 

38  if  (++next  ==  size)  next  =  0; 

39  numElts++; 

40  } 

41  } 

42 

43  /**  Get  the  capacity  of  the  buffer.  */ 

44  public  int  getMaxSize ( )  {  return  size;  } 

45 

46  /**  Get  the  number  of  elements  in  the  buffer.  */ 

47  public  int  length ()  {  return  numElts;  } 

48 

49  /**  Returns  <code>true</code>  if  the  buffer  was  empty 

50  *  before  last  put  operation.  */ 

51  public  boolean  wasEmpty  ()  { 

52  return  numElts  ==  1; 

53  } 

54 

55  /**  Returns  <code>true</code>  if  the  buffer  was  full 

56  *  before  the  last  get  operation.  */ 

57  public  boolean  wasFullO  {  return  numElts+1  ==  size;  } 

58 

59  /**  is  the  buffer  full?  */ 

60  public  boolean  isFullO  {  return  numElts  ==  size;  } 

61  } 


isFull 


Figure  5.4:  Class  BoundedFIFO  with  region,  effect,  and  locking  annotations. 
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lock  name  Z,  the  lock  identifier  e  .1  is  added  to  the  set  of  locks.  A  method  can  return  a  lock  as  a 
result;  an  expression  e .  m  ( .  .  . )  is  similarly  converted  to  lock  identifiers  based  on  the  lock  name  in 
m’s  @returnsLock  annotation. 

A  static  synchronized  method  is  treated  as  a  synchronized  block  whose  lock  expression 
is  the  pseudo-field  class.  A  synchronized  instance  method  is  treated  as  a  synchronized  block 
whose  lock  expression  is  this.  Lock  preconditions  declared  via  @requiresLock  annotations 
must  also  be  converted  to  lock  identifiers;  this  is  a  straightforward  process. 

The  lock  context  for  an  expression  is  the  set  of  locks  that  are  held  when  the  expression  is  evalu¬ 
ated.  It  is  the  union  of  the  locks  acquired  by  all  surrounding  synchronized  blocks  (also  account¬ 
ing  for  the  possibility  that  the  expression  is  in  the  body  of  a  synchronized  method)  and  of  the 
locks  assumed  to  be  acquired  by  any  @requiresLock  precondition  on  the  method  in  which  the 
expression  appeal's. 

The  general  process  for  checking  that  a  field  is  accessed  according  to  the  locking  model  is  (1) 
compute  the  lock  identifier  for  the  field  reference;  (2)  compute  the  lock  context  for  the  expression; 
and  (3)  determine  if  the  lock  identifier  from  (1)  must  name  any  of  the  locks  in  the  lock  context. 
In  general,  alias  analysis  is  required  to  compare  two  instance  locks.  We  sidestep  this  problem  in 
our  implementation  by  restricting  the  syntactic  form  of  lock  expressions.  We  require  them  to  be 
final  expressions,  by  which  we  generally  mean  an  expression  whose  value  is  constant.  Such  an 
expression  can  be  used  as  a  name  for  an  object  throughout  the  scope  in  which  it  is  defined  with  out 
having  to  worry  that  different  uses  of  the  expression  refer  to  different  objects.  The  use  of  a  final 
local  variable,  including  this,  is  a  final  expression;  a  field  reference  e .  f  is  a  final  expression  if  e 
is  a  final  expression  and  f  is  a  final  field;  a  method  invocation  e  .m  ( .  .  . )  is  a  final  expression 
if  e  is  final  expression  and  mis  a  method  with  a  @returnsLock  annotation.  A  program  can  be 
converted  to  use  only  final  expressions  by  introducing  final  local  variables. 

Only  lock  expressions  that  are  final  expressions  are  converted  into  locks.  Our  prototype  analysis 
tool  outputs  warnings  when  it  encounters  non-final  lock  expressions.  Our  implementation  compares 
locks  by  first  comparing  the  lock  names,  and  then  checking  if  the  object  expressions  are  syntactically 
identical.  We  do  not  require  that  shared  state  be  accessed  only  via  final  expressions.  However,  state 
that  is  not  accessed  via  a  final  expression  will  never  be  assured  to  have  the  required  lock  held.  The 
details  of  final  expressions  and  lock  comparisons  are  in  Section  5.11. 
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5.7  Protecting  References 

In  Java,  a  class-typed  field  actually  has  as  its  value  a  reference  to  an  object.  As  a  result,  it  is  in 
general  the  case  that  an  object  referenced  by  the  field  of  one  object  can  also  be  referenced  by  a  field 
of  another  distinct  object.  In  other  words,  unlike  C++,  Java  does  not  provide  an  explicit  mechanism 
for  incorporating  the  structure  of  one  object  into  the  structure  of  another.  This  situation  motivates 
the  use  of  uniqueness  and  @unshared  fields  within  our  region  and  effects  system  in  Chapter  4.  This 
problem  of  potential  aliases  also  impacts  how  state  is  protected.  A  lock  associated  with  a  region 
guards  the  values  of  the  fields  in  that  region.  In  case  of  class-typed  fields,  therefore,  the  reference 
only  is  protected,  not  the  object  that  is  referenced.  This  is  not  a  defect  in  the  locking  meta-model:  it 
is  in  general  unsafe  to  use  the  lock  that  protects  the  field  to  also  protect  the  referenced  object  because 
to  do  so  in  the  absence  of  additional  design  information  could  lead  to  multiple  locks  protecting  the 
same  object. 

Sometimes  this  is  what  is  desired  by  the  programmer  because  it  is  assumed  the  referenced  ob¬ 
ject  is  already  thread-safe.  That  is,  its  implementation  performs  the  actions  necessary  to  protect 
the  invariants  of  class  instances — e.g.,  by  being  immutable  or  using  locks — or  otherwise  describes 
to  clients  what  they  must  do  to  preserves  an  instance’s  invariants.  These  are  issues  of  concurrency 
policy  and  arc  further  discussed  in  Chapter  6.  The  problem  with  this  situation  is  when  it  is  not  what 
the  programmer  intends.  It  is  a  problem  because  simply  verifying  that  the  reference  to  an  object 
is  correctly  accessed  gives  no  assurance  about  the  thread-safety  or  lack  thereof  of  the  referenced 
object.  The  danger  is  that  because  our  approach  is  incremental  and  does  not  require  all  classes  to  be 
thread-safe  at  all  times,  unlike  for  example,  RaceFreeJava  [FFOO],  Guava  [BSTOO],  and  Parame¬ 
terized  RaceFreeJava  [BR01],  assuring  the  correct  use  of  a  field  can  be  misleading.  Instances  of 
the  assured  class  could  still  participate  in  race  conditions  over  the  object  that  they  reference  because 
the  referenced  object  is  shared  and  not  thread-safe. 

The  issue  for  us,  then,  is  how  to  make  analysis  less  misleading  under  these  circumstances.  Our 
solution  is  to  analyze  the  use  of  reference-valued  fields  that  arc  associated  with  a  lock  and  issue 
warnings  when  the  usage  appears  to  make  use  of  a  potentially  shared  object  that  may  be  non¬ 
thread-safe.  These  warnings  arc  not  assurance  failures:  they  do  not  reflect  inconsistencies  between 
source  code  and  annotated  design  intent.  Rather  they  are  requests  from  the  tool  for  more  information 
about  design  intent;  they  highlight  areas  where  the  additional  assurance  enabled  by  additional  design 
intent  may  be  beneficial.  The  object  referenced  by  the  protected  field  can  be  dereferenced  to  access 
a  field,  or  to  invoke  a  method.  These  uses  arc  analyzed  differently.  To  be  more  concrete,  we  consider 
a  field  reference  e .  f  where  field  f  with  declared  type  c  is  within  a  shared  region  of  the  object  of 
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type  D  evaluated  to  by  expression  e. 

For  a  field  reference  e.f.gw  e  try  to  verify  that  field  g  is  known  to  be  protected.  If  g  is  final 
or  volatile  then  it  does  not  require  protection,  and  analysis  does  not  issue  a  warning.  Otherwise 
analysis  checks  if  within  class  c  the  field  g  is  paid  of  a  shared  region.  If  so,  then  no  warning  is 
issued  because  there  is  a  lock  associated  with  this  field,  and  the  standard  lock  analyses  will  assure 
the  correct  use  of  the  field.  Alternatively,  field  f  may  be  @unshared  and  the  field  g  aggregated  into 
a  protected  region  of  the  D  instance  referenced  by  e.  Again,  the  analysis  for  assuring  the  correct  use 
of  fields  will  handle  this  case  correctly.  It  is  only  if  g  is  not  declared  to  be  protected  that  a  w  arning 
is  issued. 

For  a  method  invocation  e .  f  .  m  ( .  .  . )  we  first  check  if  the  field  f  is  @unshared.  If  it  is,  then 
the  invocation  does  not  need  to  be  additionally  protected  because  the  referenced  object  cannot  be 
accessed  by  multiple  threads  without  going  through  field  f ,  which  is  already  protected.  If  the  field  is 
not  declared  to  be  @unshared,  then  we  try  to  determine  if  objects  of  class  c  are  thread-safe.  Really 
what  we  want  to  know  is  whether  the  method  m  can  be  invoked  without  any  client-side  locking.  But 
the  absence  of  a  @requiresLock  annotation  on  m’s  declaration  does  not  indicate  design  intent  one 
way  or  the  other — the  concurrency  policy  of  the  class  needs  to  be  consulted.  It  is  enough  to  know 
that  instances  of  the  type  “take  care  of  themselves.”  The  annotation 

@self Protected 

on  class  and  interface  declarations  declares  this  intent.  This  annotation  and  concurrency  policy 
issues  in  general  are  discussed  in  Chapter  6.  If  f  is  not  @unshared  and  type  c  is  not  annotated  with 
@self  Protected  then  a  warning  is  issued. 

We  emphasize  (1)  that  these  warnings  do  not  correspond  to  inconsistencies  between  code  and 
design  intent;  (2)  that  these  w  arnings  arc  intending  to  provoke  the  programmer  into  providing  more 
design  intent ;  and  (3)  that  the  analyses  that  support  these  warnings  arc  not  intended  to  be  com¬ 
prehensive,  but  are  heuristics  intended  to  prevent  the  programmer  from  being  misled  by  positive 
assurance  results  under  certain  circumstances. 

5.7.1  BoundedFIFO’s  buf  Array 

We  use  BoundedFlFO  as  an  example  for  why  these  warnings  arc  interesting.  In  this  example,  we 
assume  that  the  field  buf  has  not  been  previously  declared  to  be  @unshared.  Indexing  into  the 
array,  as  done  in  methods  get  and  put  would  then  not  be  covered  by  the  locking  model  declared 
by  the  annotation  @lock  BufLock  is  this  protects  Instance.  As  the  code  is  currently 
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written,  the  consequences  of  this  lack  of  explicit  protection  are  obscured  because  the  array  cannot 
be  indexed  without  first  dereferencing  the  field  buf ,  which  is  explicitly  protected.  Suppose,  how¬ 
ever,  that  the  field  buf  is  declared  to  be  final  and  thus  not  protected  by  the  lock  associated  with 
Instance. 

When  analyzing  the  code  in  this  modified  state,  with  the  uniqueness  aggregation  removed  and 
with  buf  declared  to  be  final,  our  declared  locking  model 

•  Specifically  excludes  buf  from  the  protection  of  the  lock  associated  with  region  Instance. 

•  Says  nothing  about  how  the  contents  of  the  array  referenced  by  buf  arc  to  be  protected. 
In  particular,  the  silence  of  the  model  on  this  point  cannot  be  interpreted  to  mean  that  the 
contents  of  the  array  arc  possibly  shared  and  protected,  nor  can  it  be  interpreted  to  mean  that 
the  contents  of  the  array  arc  not  intended  to  be  shared  with  other  threads  and  thus  do  not 
require  protection. 

Analysis  thus  has  nothing  to  assure  regarding  field  buf  or  the  array  it  references.  But,  as  pointed 
out  above,  this  is  misleading  because  the  array  object  could  be  aliased  and  should  be  protected. 
We  observe  that  there  arc  few  scenarios  where  it  would  be  useful  to  alias  the  array  referenced  by 
buf.  This  is  the  point',  aliasing  the  array  would  violate  the  design  intent  for  the  class  and  this  intent 
should  be  made  explicit.  Analysis  augmented  with  the  above  heuristics  identifies  uses  of  the  array 
as  suspicious  because  the  class  BoundedFlFO  contains  some  concurrency  intent,  the  protection  of 
the  Instance  region.  One  way  to  address  these  warnings  is  to  introduce  protection  into  the  class 
of  the  referenced  object,  because  arrays  arc  a  primitive  object  type,  this  is  not  possible.  Instead 
the  array  must  be  aggregated  into  a  protected  region  of  the  FIFO  object,  as  originally  done  in  the 
example. 


5.8  Protecting  Aggregated  Objects 

We  show  in  Section  5.2  how  to  use  uniqueness  aggregation  to  protect  the  contents  of  the  buf  array  in 
the  BoundedFlFO  example.  Aggregation  in  this  case  maps  the  elements  of  the  array,  the  region  [] , 
into  the  Instance  region  of  the  BoundedFlFO  object;  the  mapping  is  indirect,  via  the  Instance 
region  of  the  array  object.  As  a  result  of  this  mapping,  within  the  implementation  of  BoundedFlFO, 
effects  on  target  this,  buf .  []  are  treated  as  effects  on  target  this .  Instance  and  thus  must 
occur  within  a  critical  section  synchronized  on  Buf  Lock.  Thus,  in  general,  to  check  that  an  access  to 
a  region  that  is  aggregated  into  the  region  of  another  object  conforms  to  the  locking  model,  locking 
analysis  merely  has  to  consult  the  aggregation  mappings,  and  apply  the  locking  model  as  applied  to 
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the  incorporating  region.  While  this  description  provides  the  intuition  behind  the  interaction  of  lock 
analysis  and  uniqueness  aggregation,  there  are  many  complicating  issues  that  must  be  addressed. 

Aggregating  the  contents  of  an  array  represents  the  simplest  and  most  straightforward  case  to 
handle  because  (1)  arrays  have  no  methods,  and  as  a  result  (2)  all  changes  to  the  state  of  an  array 
occur  by  direct  access  to  its  state,  and  (3)  arrays  do  not  attempt  to  protect  themselves.  We  now 
consider  the  issue  more  generally.  Suppose  that  class  Owner  has  an  unshared  field  u  that  refers  to 
an  object  of  class  C,  and  that  region  Src  of  class  c  is  mapped  into  region  Dest  of  class  Owner. 
The  superregion  of  u  is  irrelevant  to  this  example.  If  Dest  is  not  associated  with  a  lock,  then 
Src  is  protected,  or  not,  according  to  the  locking  model  of  class  C,  and  aggregation  has  no  role  to 
play  regarding  the  protection  of  shared  state.  On  the  other  hand,  if  Dest  is  associated  with  a  lock, 
then  within  the  implementation  of  Owner,  the  intuitive  semantics  of  state  aggregation  imply  that 
accesses  to  the  region  identified  by  target  this  . u.  Src  must  occur  only  when  the  lock  associated 
with  region  Dest  is  held.  Furthermore,  any  lock  associated  with  region  Src  can  be  ignored — this 
is  safe  because  the  uniqueness  of  field  u  guarantees  that  the  only  way  to  access  the  object  is  through 
its  associated  synchronization-providing  Owner  object 

Applying  Owner’s  locking  model  to  aggregated  c  objects,  however,  is  tricky  because  c  is  im¬ 
plemented  without  regal'd  to  how  it  may  be  aggregated  into  other  objects.  This  is  fundamentally  an 
issue  of  encapsulation,  scalability,  and  cutpoints.  Returning  to  our  intuitive  explanation  from  above, 
to  check  the  implementation  of  Owner,  analysis  must  rely  on  the  effects  of  operations  on  the  c  ob¬ 
ject  referenced  by  field  u.  If  the  operation  may  affect  the  region  identified  by  target  this  .  u .  Src, 
then  the  operation  is  considered  to  affect  the  region  identified  by  this  .Dest,  and  the  appropriate 
lock  must  be  held.  Direct  accesses  to  fields  in  the  aggregated  region,  e.g.,  this  . u.  f,  where  f  is  a 
subregion  of  Src,  are  simply  direct  producers  of  effects.  For  method  calls,  e.g.,  this  .  u .  m  ( ) ,  anal¬ 
ysis  must  rely  on  the  method’s  declared  effects;  determining  whether  this . u.  Src  is  affected  by 
the  method  is  a  problem  solved  in  Chapter  4.  It  may  be  the  case  that  the  declared  effects  are  overly 
broad  and  force  the  lock  for  Dest  to  be  acquired  unnecessarily:  this  is  an  unavoidable  consequence 
of  encapsulation. 


5.9  Escaping  Protection 


It  is  possible  to  escape  the  locking  model  by  abusing  upcasts.  This  is  a  consequence  of  our  interest  in 
incrementality:  we  do  not  require  that  all  fields  of  a  class  be  protected  by  a  lock,  unlike,  for  example 
RaceFreeJava  [FFOO]  and  Guava  [BSTOO].  Thus  a  class  can  associate  an  inherited  region  with  a 
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lock  as  long  as  that  region  is  not  already  associated  with  a  lock.  The  intent  here  is  clear:  uses  of  the 
region  in  instances  of  the  ancestor  class  do  not  require  protection,  but  uses  of  the  region  in  instances 
of  the  subclass  do.  An  instance  of  the  protection-requiring  subclass  may  be  accessed  through  a 
reference  whose  type  is  that  of  the  unprotected  superclass,  which  causes  the  protection  information 
to  be  lost.  This  is  a  problem  only  if  the  reference  is  used  to  directly  access  fields  of  the  object  that 
belong  to  the  now-forgotten  shared  region.  Method  calls  via  the  upcast  reference  arc  not  affected 
because  the  preconditions  of  a  method  cannot  be  strengthened  by  subclasses. 

A  possible  solution  to  this  problem  is  to  propagate  region-lock  associations  up  the  class  hier¬ 
archy.  This  is  unreasonable  because  multiple  subclasses  of  a  class  could  declare  different  locking 
models,  but  more  importantly  because  "backwards”  propagation  of  information  along  the  class  hi¬ 
erarchy  violates  principles  of  modularity  and  abstraction  and  is  counterintuitive.  A  more  reasonable 
approach  is  for  analysis  to  issue  a  warning  when  a  reference  to  an  object  of  a  class  that  adds  protec¬ 
tion  to  an  inherited  region  is  explicitly  or  implicitly  upcast.  Our  prototype  tool  does  not  check  for 
such  situations. 

5.10  Related  work 

Warlock  [Ste93]  is  a  static  analysis  tool  that  checks  for  the  inconsistent  use  of  locks  in  C  programs 
written  for  Solaris.  The  programmer  does  not  annotate  the  intended  lock-state  associations.  Instead 
the  tool  determines  which  locks  arc  held  when  a  variable  is  accessed.  Those  variables  that  arc  not 
consistently  accessed  arc  subject  to  data  races.  Annotations  arc  used,  however,  to  mark  segments 
of  code  where  locking  is  not  needed,  to  declare  lock  preconditions  on  functions,  and  to  identify 
functions  that  acquire  or  release  locks  as  side  effects. 

Both  ESC/Java  [DLNS98,  LNS00]  and  RaceFreeJava  [FF00]  associate  fields  directly  with 
locks;  we  associate  locks  with  abstract  regions,  enabling  retention  of  encapsulation  and  support  for 
program  evolution  and  subclassing.  ESC/Java  incorporates  locking  information  into  the  verification 
condition.  RaceFreeJava  statically  checks  for  unsynchronized  access  to  state  using  a  type-based 
approach  [FA99a,  FA99b].  While  [FA99b]  describes  using  existential  types  in  a  manner  similar  to 
our  “returns  lock”  annotation,  RaceFreeJava  does  not  implement  this  feature  because  it  requires 
resolving  aliasing  among  objects.  We  avoid  this  problem  by  identifying  canonical  lock  references. 
As  discussed  in  Section  4.10,  ESC/Java  does  not  support  state  aggregations.  Classes  in  RaceFree¬ 
Java  may  be  parameterized  by  locks,  which  is  similar  to  our  state  aggregation,  but  the  system  has  no 
formal  model  of  named  object  state.  The  lock  that  protects  access  to  the  elements  of  an  array  may  be 
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identified  [FQ03a],  but  how  the  identity  of  the  array  is  preserved  is  not  described.  RaceFreeJava 
supports  thread-local  classes  which  arc  not  currently  expressible  in  our  system.  RaceFreeJava 
has  been  extended  [FF01]  to  handle  additional  programming  patterns  found  to  be  common  sources 
of  false  alarms.  New  annotations  include,  for  example,  an  annotation  indicating  the  tool  should  act 
as  if  the  object’s  lock  is  held  while  the  constructor  is  executing.  They  do  not  assure  anything  as 
a  result  of  this  annotation;  it  is  merely  a  flag  for  turning  off  “false  alarms.”  Neither  ESC/Java  nor 
RaceFreeJava  can  represent  unique  pointers. 

As  described  in  Section  4.10,  object  ownership  [CPN98]  models  transitively  aggregate  the  state 
of  an  object  into  the  state  of  its  owner.  Guava  [BST00]  and  Parameterized  RaceFreeJava  [BR01] 
use  object  ownership  as  the  basis  for  protecting  shared  state.  Object  ownership  allows  protection 
only  at  the  granularity  of  objects.  The  state  of  an  object  cannot  be  split  across  multiple  owners, 
and  thus,  for  example,  the  classes  ThreadCache  and  CachedThread  of  Figure  4.5  in  their  current 
form,  cannot  be  expressed  in  object-ownership-based  systems.  Guava  is  a  dialect  of  Java  without 
a  general  synchronization  construct.  Instead,  classes  belong  to  one  of  three  categories:  sh arable 
monitors,  sharable  deep-copied  values,  and  unsh arable  objects.  Object  ownership  prevents  sharing 
of  objects:  each  object  has  exactly  one  owning  monitor  or  value,  and  cannot  change  its  owner.  Guava 
sacrifices  flexibility  for  safety,  whereas  we  ultimately  desire  to  enable  implementation  flexibility  and 
evolution  while  maintaining  safety,  and  to  do  this  for  existing  code,  as  in  our  case  studies. 

Parameterized  RaceFreeJava  uses  a  type-system  to  enforce  locking  conventions.  It  is  dis¬ 
tinguished  by  allowing  classes  to  be  generic  in  their  protection  mechanisms,  which  are  specified 
when  instances  arc  created.  Protection  is  based  on  object  ownership:  every  object  has  exactly  one 
fixed  owner  that  is  specified  through  parameterization.  Objects  representing  owners  may  be  given 
as  method  preconditions.  Before  accessing  a  field  of  an  object  or  invoking  a  method  with  an  object 
precondition,  the  lock  on  the  object  at  the  root  of  the  ownership  hierarchy  of  the  object  must  be 
held.  Thread-local,  unique,  and  immutable  objects,  cases  that  do  not  require  synchronization,  arc 
handled  using  special  owners. 

The  Vault  programming  language  [DF01]  statically  tracks  keys  (capabilities)  associated  with 
fields  and  variables  to  enforce  resource  management,  such  as  locking  protocols.  Keys  can  model 
non-hierarchical  regions.  The  state  of  an  object  may  be  aggregated  into  multiple  other  objects  by 
parameterizing  types  by  keys.  However,  no  general  state  naming  system  is  provided  beyond  the 
key-field  associations  the  programmer  chooses  to  make.  Vault  tracks  key  aliases,  and  enforces  key 
uniqueness,  but  provides  no  mechanism  for  ensuring  the  uniqueness  of  an  object  reference.  An 
advantage  of  Vault  is  that  it  does  not  require  lock  management  to  be  syntactically  scoped,  but  it 
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defn 
region 
lockdef 
lock 
field 
shared_field 
unshared  _Jield 

agg 

meth 


class  cn  extends  c  {region*  lockdef*  field*  meth*} 

region  argn  in  argn 

lock  In  is  lock  protects  rgn 

this  |  fd 

shared_field  \  unshared _field 
mod_t  fd  i  n  argn  =  e 

unshared  mod_t  fd  in  argn  aggregate  agg+  =  e 
rgn  into  argn 

t  mnm{arg*)  requires  In*  [returns  ln]opt  {body} 


The  disjoint  name  spaces  are  extended  with  the  set  of  abstract  region  names  and  lock  names.  The 
set  of  region  names  is  the  set  of  abstract  region  names  together  with  the  set  of  field  names. 

In  £  lock  names  rgna  £  abstract  region  names  rgn  £  field  names  U  abstract  region  names 

_ Figure  5  Syntax  modifications  to  Ft  mnlAVAwith  lnheled  expressions  for  regions  and  locks _ 


provides  no  structure  in  the  use  of  keys  for  locking  purposes.  The  programmer  must  describe  the 
locking  conventions,  including  the  lock  acquisition  and  release  mechanisms,  using  key  annotations. 
It  is  not  possible  to  describe  reentrant  locks.  Because  keys  can  be  used  for  many  purposes,  e.g., 
preventing  memory  leaks,  or  enforcing  object  protocols,  it  cannot  be  assumed  that  any  particular 
key  defines  a  field-lock  relationship. 


5.11  Safe  Locking  in  FluidJava 

We  present  named  locks  as  an  extension  of  FluidJava  with  labels,  and  not  as  a  extension  of  the  lan¬ 
guage  with  effects.  This  presentation  does  not  consider  uniqueness  aggregation  when  determining 
which  lock  is  required  to  access  a  field,  and  thus  we  do  not  require  effects.  Removing  effects  from 
consideration  simplifies  the  presentation  of  locking  concerns. 

The  syntax  of  FluidJava  is  modified  as  shown  in  Figure  5.5.  Lock  declarations  associating  a 
named  lock  with  a  representation,  either  the  receiver  or  a  field  of  the  class,  and  a  region  of  state  arc 
added  to  class  declarations.  Methods  must  now  list  zero  or  more  required  locks  that  must  be  held  by 
the  caller  in  order  to  invoke  the  method.  A  method  may  optionally  have  a  returns  clause  declaring 
that  the  object  returned  by  the  method  is  the  named  lock  for  the  receiver. 

We  carry  over  the  following  notational  machinery  from  FluidJava  extended  with  effects  (see 
Figure  4.7): 

•  The  predicates  Regions O nee (P),  WFRegions(P),  and  CompleteRegions(P)  for  re¬ 
gions,  and  AggregationsOK(P)  and  MapOK  for  aggregation  mappings. 
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LocksOnce(P)  =  \/ln,  In'  :  class  ••■{■■■  lock  In  •  ■  ■  lock  In'  ■  ■  ■}  is  in  P  =>  In  ^  In' 

c.ln  Cc  c  class  c  ■  lock  In  ■  ■  •}  is  in  P 

c'.ln  £c  c  •£»  c'.ln  t£c  d  Ac  <c  c' 

In  A  c.Zn  4=>-  3c  :  c.ln  £c  c 

c.in  is  this  class  c  ■  lock  In  is  this  •  •  •}  is  in  P 

c.ln  is  d .fd  (class  c  •••{■■  ■  lock  In  is  fd  ■  ■  •}  is  in  P)  A  (3d ,  c  :  (c' .fd,  final  c)  £c  c) 

c.in  protects  c' .rgn  (class  c  •••{■■  ■  lock  In  is  ZocA;  protects  rgn  •  •  •}  is  in  P)  A  rgn  >—>  d .rgn 

W  FLockDefs  ( P)  = 

(Vc,  ln,fd,  rgn  :  class  c  ••■{■■  ■  lock  In  is  fd  protects  rgn  •  ■  ■}  is  in  P  \ 

=>  3c' ,  c"  :  c.ln  is  c! .fd  A  c.ln  protects  c" .rgn  J 

A  (Vc,  In,  rgn  :  class  c  ■  lock  In  is  this  protects  rgn  ■  ■  ■}  is  in  P  =>■  3c”  :  c.ln  protects  c" .rgn) 
NoShadowing(P)  =  . . .  A  ( c.ln  £EC  c  =*>  fic'  :(c^c'Ac<c  c'A  c!  .In  €=c  c')) 

ProtectedOnce(P)  = 

Vc,  o’,  rgn,  In  :  ( c.ln  protects  c' .rgn)  =>  (/3c,  c',  n/n',  In'  :  (c' .rgn  <r  c.' .rgn'  A  c.ln'  protects  c' .rgn')) 
LocksOK(P)  =  Vc,  mn,  Zn  :  class  c  •  mn(-  ••)•••  In  •••{•••}•••}  is  in  P  In  A  d .In 
(mn,  ti...tn  —*t,  {ln\ . . .  lnm},  0,  (xi  . . .  Xn),  e)ecc 

class  c-  t  mniu ([final]opt  ti  [xi}^^  . .  .  [final]opt  tn  [xn]ibi„) 

requires  ln\  . . .  lnm  { e }  ■  •  •}  is  in  P 
(mn,  h  . . .  tn  —>  t,  {lm  . . .  lnm},  {ln'}(x i . . .  Xn),  e)e°c 

class  c-  t  mnibi([ final]opt  ti  [xi \ibit  ■  ■  ■  [final]opt  tn  [xn}ibin) 

requires  ln\  . . .  lnm  returns  In'  { e}  •  •  •}  is  in  P 
ClassMethodsOK(P)  =  Vc,  c' ,  e,  d ,  mn,  U,  t[,  t,  t' ,  L,  L' ,  Lret,L'ret,  V,  V'  : 

((mn,  Zi  . .  .tn  — >  t,  L,  Lret,  V,  e)£ccA  (mn,  t'  i  . . .  t'n  — >  t' ,  L',L'ret,  V' ,  e')£cc') 
_ =»  ((t  =  t'  A  U  =  t'i  A  L  =  L'  A  Lret  =  L'ret  f\  V  =  V')  V  (c  c')) _ 


Figure  5.6:  Additional  predicates  and  relations  for  checking  FluidJava  extended  with  locks. 
Metavariable  L  is  a  set  of  lock  names. 


•  The  relations  pr,  <r,  and 

•  The  triple  rgn  d .rgn. 

•  The  region-related  extensions  to  (Ec  and  Gc. 

Additional  predicates  and  relations  related  to  locks  are  defined  in  Figure  5.6.  LocksOnce(P) 
insures  a  lock  name  is  unique  within  a  class  declaration.  The  relations  and  Gc  are  extended  to 
include  lock  names.  The  triple  In  dd  c.ln  converts  a  lock  name  into  a  qualified  lock  name  relative 
to  the  class  c.  The  new  relation  is  maps  a  lock  to  its  representation;  when  the  representation  is 
a  field,  the  relation  is  only  defined  if  the  field  is  final  and  a  reference  to  an  object,  i.e.,  something 
that  can  be  locked.  Similarly,  the  new  relation  protects  maps  a  lock  name  to  the  region  it  protects, 
and  is  only  defined  if  the  region  exists  in  the  class  in  which  the  lock  is  declared.  The  predicate 
WFLockDefs(P)  is  true  only  when  all  the  lock  declarations  in  a  class  are  well  formed,  that  is, 
have  defined  is  and  protects  mappings.  Predicate  NoShadowing(P)  is  extended  to  prevent 
lock  names  from  being  shadowed.  Predicate  ProtectedOnce(P)  makes  sure  that  if  a  region  is 
protected,  it  is  not  a  subregion  of  another  protected  region. 
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Predicate  LocksOK(P)  ensures  that  all  the  locks  named  in  requires  and  returns  clauses  arc 
present  in  the  class  in  which  the  method  is  declared.  The  method  structure  in  relation  £?  is  altered 
to  include  the  set  of  required  locks  and  the  return  lock,  if  any;  relation  €f,  not  shown,  is  updated 
in  the  obvious  manner.  A  method  can  only  return  a  single  lock,  but  we  use  a  set  of  cardinality  zero 
or  one  to  more  easily  handle  the  case  when  the  method  is  not  declared  to  return  a  lock.  We  update 
Class M ethodsOK(P)  to  require  that  method  overriding  preserve  lock  preconditions  and  returns 
clauses. 

5.11.1  Locks  and  Aliasing 

Locks  arc  represented  as  a  pair  of  an  expression  with  a  lock  name,  e.g.,  (this.f,  c.lock);  this  lock  is 
the  lock  named  “lock”  declared  in  class  c  of  the  object  referenced  by  expression  this.f.  In  this  way, 
locks  arc  similar  to  instance  targets,  and  have  the  same  aliasing  problems.  We  resort  to  syntactic 
restrictions  similar  to  those  of  [FF00]  to  avoid  having  to  resolve  lock  aliases.  An  expression  that  is 
interpreted  as  a  lock  must  be  a  final  expression,  by  which  we  generally  mean  an  expression  whose 
value  is  constant.  Such  an  expression  can  be  used  as  a  name  for  an  object  throughout  the  scope  in 
which  it  is  defined  with  out  having  to  worry  that  different  uses  of  the  expression  refer  to  different 
objects.  We  require  that  the  lock  expression  in  a  synchronized  block  be  a  final  expression.  Final 
expressions  arc  formally  defined  in  the  next  section,  but  in  general  arc  built  from  final  local  variables 
and  accesses  to  final  fields. 

5.11.2  Type  Rules  for  Locks 

We  must  modify  the  typing  judgment  for  expressions  to  incorporate  the  current  lock  context  or  set 
of  locks  known  to  be  held  when  the  expression  is  evaluated.  We  also  introduce  a  new  judgment 
for  typing  final  expressions  whose  results  also  include  the  set  of  locks  that  the  expression  must 
represent: 

P;P;  C  F  e  :  t 
P,  P,  C  I  final  6  •  t  OS  L 

Lock  context  C  and  lock  result  L  are  sets  of  locks  {(d,  c.ln)}. 

The  well-formedness  rules  rules  for  Fluid  Java  extended  with  locks  arc  shown  in  Figure  5.7. 
Programs  arc  checked  against  the  additional  lock-related  predicates  and  the  program  body  is  eval¬ 
uated  with  an  initially  empty  lock  context.  For  each  method,  its  body  is  checked  using  the  locks 
declared  to  be  required  as  the  initial  lock  context.  The  lock  names  arc  converted  to  locks  of  the 
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Prog 

ClassOnce(P)  RegionsOnce(P)  MethodsOnce(P)  NoShadowing(P) 

CompleteClasses(P)  WFClasses(P)  ClassMethodsOK(P)  UniqueLabels(P) 

WFRegions(P)  CompleteRegions(P)  AggregationsOK(P)  LocksOnce(P)  WFLockDefs(P) 
ProtectedOnce(P)  LocksOK(P)  P  =  deftly  . . .  defnn  e  Ph  defni  P;  0;  0  h  e  :  t 

hP:( 


Class  Field 

P,  cn  h  fieldi  P,  cn  h  methi  Phi  P;I;U  h  e  :  I 

P  h  class  cn  extends  c'  ■  ■  ■  {■  •  ■  jield1  . . .  field  ■  methi  . . .  meth j,}  P,  c  h  [f i na l]opt  t  fd  in  rgn  =  e 

UnsharedField 

Phc'  P;  0;  0  h  e  :  c'  MapOK(P,  Mcfi ,  c') 

P,  c  h  unshared  [final]opt  c'  fd  in  rgn  aggregate  agg1  . . .  aggn  =  e 

Method 

Pht  Ph  mod_ti  E  =  final  cthis,  mod_t\  xi, . . . ,  mod_tn  xn 
P;  E\  {(this,  a. Ini)  \  Ini  *-*  Ci.lni}  h  e  :  t  fp  3  { (Z£>Z ,  E),  (Ibli ,  E), . . . ,  (lbln,  E)} 

P,  c  h  t  mnibi(mod_t1  [xi ]ibit  . . .  mod_tn  [x„\ibin)  requires  Ini . . .  lnm  {e} 
MethodReturnsLock 

P  h  t 

P  h  mod_ti  E  =  final  cthis,  mod_t\  xi, . . . ,  mod_tn  xn  P;  E\  {(this,  a. Ini)  \  Ini  *-*  Ci.lni}  Ffinal  e  :  t  as  L 
In  t-y  c.ln  {(this,  c.ln)}  C  L  £P  D  {(Ibl,  E),(lbli ,  E), . . . ,  {lbln,  E)} 

P,cl-f  mnn,i{mod_ti  [xi]^^  ■  ■  ■  mod_tn  [^n]i6i„)  requires  ln\  . . .  lnm  returns  In  {e} 


Figure  5.7:  Well  formedness  rules  for  FluidJava  extended  with  locks. 


receiver  using  the  triple  In  ^7  c' .In.  In  this  way,  the  body  is  evaluated  assuming  that  the  method 
will  be  called  correctly.  If  a  method  has  a  returns  clause,  the  lock  declared  to  be  returned  is  checked 
against  the  set  of  locks  that  the  body  of  the  method  is  known  to  represent.  The  body  of  the  method 
must  be  a  final  expression  in  this  case.  In  real  Java,  we  would  instead  check  the  value  of  each 
return  statement  in  the  method’s  body,  and  require  that  each  return  statement  return  a  final  ex¬ 
pression. 

Most  of  the  rules  for  typing  expressions  just  propagate  the  lock  context  without  using  it  or 
altering  its  contents.  The  interesting  cases  arc  those  expressions  that  can  be  interpreted  as  a  locks 
or  that  require  lock  information.  Figure  5.8  shows  the  rules  for  reading  a  local  variable.  The  first 
rule  Var  is  the  standard  rule  for  variable  use.  But  the  second  rule  is  the  first  of  several  judgments 
defining  final  expressions.  A  final  local  variable  is  a  final  expression.  The  locks  represented  by  the 
expression  arc  derived  from  those  lock  names  declared  in  the  type  of  the  variable  that  arc  represented 
by  the  object  itself,  i.e.,  this.  This  lock  generation  process  is  embodied  in  the  helper  function 
objAsLocks(P,  e,  t),  which  returns  the  empty  set  when  t  is  a  non-object  type. 

More  interesting  are  the  rules  for  field  access,  shown  in  Figure  5.9,  because  such  expressions 
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objAsLocks(P,  e,  t) 


f  0  when  t  E  { i nt,  boolean} 

\  { ( e,  c.ln )  |  t  <c  c  A  c.ln  is  this}  otherwise 


Var  VarFinalExpr 

E  =  Et,  [final]opt  tx,E2  E  =  Ei,  final  t  x,  E2 

P;  E]  C  h  x  :  t  P\E\C  Ffmal  x  :  t  as  objAsLocks(P,  x,  t ) 


Figure  5.8:  Rules  for  reading  local  variables. 


lockFor(P,  e,  c.fd,t)  =  {(e,  c.ln)  \  t  <°  c  A  c.fd  <r  c' .rgn  A  c.ln  protects  c' .rgn} 

fdAsLocks(P,  e,  c.fd ,  t)  =  {(e,  c' .In)  \  t  <c  c'  A  c' .In  is  c.fd} 

Get  GetFinal 

P;E;Ch  e  :  c  (c'.fd,t)€cc  lockFor(P,  e,  c'.fd,  c)  C  C  P;E;C\-e:c  (c'.fd,  final  t)  Sc  c 

P-E;C\-  e.fd  :  t  P;B;Ch  e.fd  :  t 

GetFinalExpr 

P;  E ;  C  Ffinai  e  :  c  as  L  {c'.fd,  final  t)  Sc  c 
P;  F;  C  I- fina,i  e.fd  :  t  as  fdAsLocks(P,  e,  c' .fd,  c)  U  obj  AsLocks(P,  e.fd ,  t) 

Set 

P;E;Che:c  (c'./d,  t)  Sc  c  P;B;Che':i  lockFor(P,  e,  c'.fd ,  c)  C  C 

P;B;Ch  e./d  =  e'  :  i 

Figure  5.9:  Rules  for  expressions  that  access  fields. 


can  both  be  locks  and  require  the  holding  of  a  lock.  The  function  lockFor(P,  e,  c.fd,  t)  gives  the 
lock  required,  if  any,  to  access  the  field  c.fd  of  the  object  referenced  by  e  of  type  t  in  program  P 
by  finding  an  ancestor  region  of  c.fd  that  is  associated  with  a  lock  defined  in  t.  Although  the  result 
is  a  set,  the  set  must  have  a  cardinality  of  either  zero,  if  the  field  is  not  associated  with  a  lock,  or 
one,  if  the  field  is  associated  with  a  lock.  A  set  is  used  to  make  dealing  with  the  absence  of  a  lock 
easier.  Reading  from  a  non-final  field  may  require  lock.  The  current  lock  context  is  checked  to  see 
if  it  contains  the  required  lock.  Reading  from  a  final  field  is  similar  except  that  no  lock  is  required 
to  access  it.  The  required  lock  is  checked  when  writing  to  a  field. 

Reading  from  a  final  field  is  a  final  expression  if  and  only  if  the  subexpression  evaluating 
to  the  dereferenced  object  is  a  final  expression.  The  field  reference  can  represent  locks  from 
two  objects:  (1)  locks  represented  by  the  field  fd  of  the  object  e,  handled  by  the  helper  func¬ 
tion  fdAsLocks(P,  e,  c.fd ,  t);  and  (2)  locks  represented  by  this  of  the  object  e.fd,  handled  by 
objAsLocks(P,  e  ■fd,  t). 

The  rules  for  method  invocation  are  shown  in  Figure  5.10.  A  method  can  only  be  invoked  if  the 
locks  it  requires  arc  present  in  the  current  lock  context.  In  the  case  of  normal  method  invocation  the 
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locksFromSet(P,  L,  e,  c)  =  {(e,  c' .In)  \  In  G  L  A  In  ^  c' .In} 


Invoke 

P\  E\  C  \~  ei  :  ti 


P-E-CV-  e:  c 

( mn ,  tl  .  .  .  tn  — *  t,  Lreq ,  Fref,  V,  e&)  G°  C  locksFromSet  (P,  Lre(?,  6,  c)  C  C 
P;  F;  C  h  e.mn(ei  . . .  en)  :  £ 


InvokeFinalExpr 


P;  F;  C  \~ final  e  :  c  as  L 

P;  F;  C  b  ei  :  £j  (mn,  £1  . . .  tn  — >  £,  Lreg,  Fret,  V,  e*,)  Gc  c  IocksFromSet(P,  Lre(?,  e,  c)  C  C 
P;  F;  C  Ffinai  e.mn(ei  . . .  en)  :  t  as  JocksFromSet (P,  Fret,  e,  c) 


Super 

P;  F;  C  hfinai  super. mn(ei  . . .  en)  :  t  as  L 
P;  E;  C  b  super. mn(ei  . . .  en)  :  £ 


SuperFinalExpr 

P;  F;  C  b  this  :  c7  cr  -<c  c  (mn,  £1  . . .  £n  — »  £,  Lreq ,  Lref,  V,  e&)  Gc  c 
e\)  7^  abstract  P;  F;  C  b  ej  :  ti  locksFromSet(P,  Lreq,  this,  c)  C  C 

P;  F;  C  F finai  super. mn(ei  .. .  en)  :  t  as  locksFromSet(P,  Lret,  this,  c) 


Figure  5.10:  Rules  for  method  invocation. 


Sync 

P\  E ;  C  Hfinai  ej  :  c  as  L  P\  E ;  (C  U  L)  h  eg  :  t 
P;E;C\~  synchronized(ej )  {eg}  :  t 


Figure  5.11:  Rule  for  synchronized  blocks. 


required  lock  names  arc  converted  to  locks  of  the  receiver  expression  e.  When  invoking  a  method 
on  the  super  class,  the  receiver  is  this,  and  the  locks  arc  looked  up  with  respect  to  the  super  class.  A 
method  call  is  a  final  expression  if  the  receiver  expression  is  a  final  expression.  Super  method  calls 
are  always  final  expressions  because  the  receiver  can  be  named  by  this.  A  final  method  invocation 
represents  the  lock,  if  any,  declared  to  be  returned  by  the  method  with  respect  to  the  receiver  object. 

The  rule  for  the  synchronized  block  is  shown  in  Figure  5.11.  This  rule  is  the  ultimate  consumer 
of  the  expression-as-lock  information.  The  lock  expression  ej  is  required  to  be  a  final  expression, 
and  the  set  of  locks  it  must  represent  arc  added  to  the  lock  context  used  to  evaluate  the  body  of  the 
block,  e£. 

Rules  for  the  remaining  expressions  arc  shown  in  Figure  5.12.  These  expressions  do  not  re¬ 
quire  checking  any  lock-related  properties,  nor  do  they  directly  result  in  locks.  The  fork  expression 
evaluates  its  body  in  an  empty  lock  context:  this  is  because  new  threads  do  not  hold  any  locks. 
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Sub 

P;  E\  C  h  e  :  c'  c'  <c  c 


P  ,E  -C\-  e-.c 


Null 

P  b  c 


P;P;  C  h  null  :  c 


New 

P  h  c  NoAbstractMethods(P,  c) 

P\E\C  h  new  c  :  c 


Assign  If 

P;  E\  C  e  :  t  E  =  Ei ,  t  x.  Eg  P;  P;  C  h  ej  :  boolean  P:  E:  C  \~  eg  :  t  P;  E;  C  h  e3  :  t 


P;  E;  C  b  x  =  e  :  t  P;  E;  C  b  if (ej )  {eg}  else  {es}  :  f 


Let 

mod_t  =  [final]opt  f  x  £  E  P;  E\  C  h  ej  :  t  P;  E,  mod_t  x;  C  b  eg  :  t1 
P',  E;  C  h  let  mod_t  x  =  ej  in  {eg}  :  t' 


Fork 

P;P;0  h  e  :  t 
P;B;Ch  fork  {e|  :  int 


Seq  Abstract  Label 

P;E-Chei:ti  P;E;C\~eg:tg  P  b  t  P;  P;  C  h  e  :  t  fp  D  {(ZfeZ,  P)} 

P;  P;  C  h  er ;  eg  :  fg  P;£;Ch  abstract  :  t  P;  P;  C  h  [e]/j,/  :  t 

LabelFinalExpr 

P;  P;  C  Ff;nai  e  :  t  as  L  fp  D  {(Ibl,  E)} 

Pj  Pi  c  F flnai  [e];i,i  :  t  as  L 


Figure  5.12:  Rules  for  expressions  that  are  neutral  on  locks. 


Chapter  6 


Concurrency  Policy 


The  concurrency-related  models,  and  the  annotations  expressing  them,  discussed  thus  far  have  been 
directly  concerned  with  the  mutable  state  of  a  program  and  the  locks  used  to  protect  it.  These 
models  are  sufficient  for  describing  a  large  portion  of  the  concurrency-related  design  intent,  partic¬ 
ularly  in  programs  that  do  not  make  sophisticated  use  of  concurrency.  These  models  are,  however, 
insufficient  for  describing  important  concurrency-related  design  intent  concerning  which  methods 
of  a  class  may  execute  concurrently  while  nonetheless  maintaining  the  unstated  representation  in¬ 
variants  of  the  class.  We  introduce  the  notion  of  concurrency  policy  to  capture  this  design  intent. 
The  root  causes  of  the  problems  in  the  Buff  eredlnputstream  example  of  Section  1.4  arc  (1)  the 
failure  of  the  implementors  of  the  class  to  specify  a  concurrency  policy,  and  (2)  the  failure  of  the 
implementors  of  clients  to  respect  the  unstated  concurrency  policy. 

Let  us  consider  an  additional  example  to  further  motivate  the  expression  of  concurrency  policy. 
Figure  6.1  shows  four  versions  of  the  class  EventQueue,  differing  only  in  their  use  of  synchro¬ 
nization.  The  difference  in  lock  acquisitions  does  matter,  and  it  affects  the  value  computed  by 
getsize.  Indeed,  the  whole  point  is  to  affect  the  result  of  getsize.  The  extra  lock  represented  by 
the  field  gsLock  determines  whether  getsize  accounts  for  the  addition  or  removal  of  a  priority 
event  that  may  be  occurring  concurrently  with  the  execution  of  getsize.1  The  class  in  Figure  6. Id 
is  the  simplest  of  the  four — it  does  not  use  the  lock  gsLock.  In  particular,  as  a  result  the  methods 
enqueuePriority  and  dequeuePriority  can  execute  after  getsize  has  read  from  numHigh 
but  before  it  has  computed  the  total  number  of  items  in  the  queue  by  summing  the  number  of  priority 
and  non-priority  elements.  The  other  three  versions  of  the  class  arc  as  follows: 

1  We  acknowledge  the  contrived  nature  of  this  example,  particularly  with  the  respect  to  the  extent  of  lock  acquisitions, 
but  it  is  useful  for  explaining  the  problem  that  concurrency  policy  is  meant  to  solve. 
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•  Figure  6.1a  implements  an  “upper  bound”  getsize,  in  which  enqueuePriority  is  not 
allowed  to  execute  concurrently  with  getsize.  The  computed  size  is  maximized  because 
priority  elements  are  allowed  to  be  removed  from  the  queue  after  the  number  of  priority 
elements,  stored  in  numHigh,  is  read,  but  no  priority  items  arc  allowed  to  be  added  to  the 
queue. 

•  Figure  6.1b  implements  a  “lower  bound”  getsize,  in  which  dequeuePriority  is  not  al¬ 
lowed  to  execute  concurrently  with  getsize.  The  computed  size  is  minimized  because  pri¬ 
ority  elements  arc  allowed  to  be  added  to  the  queue  after  the  number  of  priority  elements  is 
read,  but  no  priority  items  are  allowed  to  be  removed  from  the  queue. 

•  Figure  6.1c  implements  an  “exact”  getsize,  in  which  neither  enqueuePriority  or  de¬ 
queuePriority  are  allowed  to  execute  concurrently  with  getsize.  Thus  no  changes  to 
the  number  of  priority  elements  in  the  queue  arc  allowed  while  the  size  of  the  queue  is  being 
calculated. 

All  four  versions  of  EventQueue  acquire  the  lock  represented  by  the  field  high  before  ac¬ 
cessing  the  fields  numHigh  and  high.  Similarly,  all  four  versions  acquire  the  lock  represented  by 
the  field  normal  before  accessing  the  fields  numNormal  and  normal  (usages  of  this  field  other 
than  as  a  lock  arc  elided).  We  assert  that  all  these  usages  arc  consistent  with  an  unshown  locking 
model.  The  only  real  difference  between  the  four  classes  is  in  their  use  of  the  lock  represented  by 
field  gsLock,  a  lock  that  is  not  associated  with  any  state.  Without  this  lock,  it  is  not  possible  to 
obtain  the  different  behaviors  in  method  getsize.  The  point  is  that  associations  between  locks 
and  state  are  not  always  sufficient  to  account  for  the  invariants  that  must  be  maintained  by  a  class. 
In  particular,  the  internal  state  of  the  queue  is  not  corruptible  in  any  of  the  four  versions,  but  the 
meaning  of  the  getsize  operation  varies  among  them,  and  certain  interleavings  may  be  acceptable 
with  respect  to  internal  state  and  intended  client  meaning. 

To  see  this  problem  at  a  lower  level  of  granularity,  consider  that  models  of  lock-state  association 
allow  method  dequeuePriority  to  be  implemented  as  shown  in  Figure  6.2.  This  implementation 
always  accesses  state  according  to  the  locking  model  but  is  clearly  “broken”  because  the  contents 
of  the  Vector  referenced  by  high  cannot  be  allowed  to  change  after  checking  that  the  size  of  the 
Vector  is  nonzero.  Indeed,  a  program  written  such  that  every  synchronized  block  accessed 
exactly  one  protected  field  would  be  consistent  with  its  locking  model,  but  in  practice  full  of  race 
conditions.  This  is  because  the  point  of  acquiring  locks  is  to  protect  representation  invariants.  Why 
then  the  long-standing  practice  of  associating  locks  with  state?  Locks  are  associated  with  sets 
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Figure  6.1:  Four  versions  of  EventQueue  that  differ  only  in  the  number  and  scope  of  critical 
sections. 
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private  EQEvent  dequeuePriority ( ) { 

Object  e  =  null; 
int  size; 

synchronized (  high  )  {  size  =  numHigh;  } 

if  (  size  ! =  0  )  { 

synchronized (  high  )  {  e  =  high. remove (  0  );  } 

synchronized (  high  )  {  numHigh  -=  1;  } 

} 

return  e; 

} 


Figure  6.2:  An  implementation  of  dequeuePriority  that  follows  the  locking  model  of  its  class 
but  that  obviously  has  race  conditions. 


of  fields,  regions  in  our  locking  model,  because  it  is  convenient:  most  of  the  time  the  invariants 
associated  with  the  set  of  fields  can  be  preserved  by  simply  acquiring  the  appropriate  lock  before 
accessing  the  region. 


6.1  Observing  State  Changes 

The  missing  design  intent  that  would  prevent  dequeuePriority  from  being  implemented  as  in 
Figure  6.2  is  information  on  which  portions  of  code  arc  allowed  to  observe  changes  to  shared  state. 
When  explicit  representation  invariants  arc  available,  this  information  is  potentially  deducible  from 
the  code,  formal  pre-  and  postconditions,  and  the  invariants.  Portions  of  code  that  temporarily 
invalidate  invariants  should  not  interleave  with  other  portions  of  code  that  access  the  state  whose 
invariants  arc  invalidated.  Returning  to  class  EventQueue  and  method  dequeuePriority,  an 
obvious  invariant,  stated  informally,  is  that  “numHigh  should  always  equal  the  number  of  elements 
in  the  vector  referenced  by  high.”  Clearly,  then,  no  other  thread  should  be  allowed  to  access  high 
or  numHigh  between  the  removal  of  an  element  on  line  6  and  the  decrement  of  the  element  count 
on  line  7. 

A  fundamental  premise  of  this  work,  however,  is  that  it  is  generally  unreasonable  to  require 
programmers  to  explicitly  express  representation  invariants.  Programming  tools  based  on  represen¬ 
tation  invariants  such  as  ESC/Java  [FLL+02]  appear-  to  suffer  from  poor  adoptability,  to  the  extent 
that  invariant  inference  engines  such  as  Houdini  [FJL01,  FL01]  have  been  developed  to  make  the 
code  annotation  process  less  painful.  We  introduce  the  notion  of  concurrency  policy  as  a  surro¬ 
gate  for  unstated  representation  invariants  that  still  allows  the  programmer  to  differentiate  between 
“good”  and  “bad”  concurrency.  We  believe  that  programmers  can  specify  concurrency  policy  with- 


6.2.  EXPRESSING  CONCURRENCY  POLICY 


113 


out  first  having  to  formally  express  the  representation  invariants  for  a  class;  rather,  concurrency 
policy  can  be  developed  based  on  informal  code-focused  arguments  based  on  intuitive  notions  of 
what  will  “break”  the  code.  Examples  of  such  arguments  arc  given  in  Sections  6.3.1  and  6.5.1. 


6.2  Expressing  Concurrency  Policy 

The  concurrency  policy  of  a  class  implementation  specifies  which  segments  of  code  methods  have 
potential  executions  that  can  be  safely  interleaved.  We  choose  to  focus  on  interleaved  executions 
because  it  is  fundamentally  this  interleaving  that  allows  changes  to  shared  state  to  be  observed 
across  threads.  In  the  simplest  formulation,  concurrency  policy  is  expressed  as  a  symmetric  boolean 
matrix  indexed  by  method  names.  For  larger  classes,  there  is  a  potential  combinatorial  challenge 
which  can  be  mediated  using  several  possible  techniques.  These  include  (1)  indexing  the  matrix  by 
regions  or  effects  and  deriving  a  method-indexed  matrix  from  this,  and  (2)  indexing  the  matrix  by 
sets  of  related  methods,  e.g.,  getters  and  setters,  with  obvious  derivation  of  the  full  matrix.  There  is  a 
natural  tradeoff  between  succinctness  and  expressiveness  of  these  policy  descriptions.  For  example, 
the  matrix  could  be  indexed  by  arbitrary  code  segments  of  a  class,  which  would  provide  perhaps 
finer-grained  interleaving  at  the  expense  of  more  costly  policy  expression.  These  options  are  briefly 
revisited  in  Section  6.5. 

Concurrency  policy  is  useful  not  only  to  the  implementor  of  a  class,  but  also  to  the  clients  of  a 
class.  For  example,  is  the  client  allowed  to  invoke  methods  close  and  read  of  class  Buf f ered- 
Inputstream  concurrently?  We  thus  distinguish  between  two  uses  of  concurrency  policy:  internal 
policy  that  restricts  the  implementation  of  a  class,  and  external  policy  that  restricts  the  use  of  a 
particular  implementation.2  These  uses  are  described  in  more  detail  in  the  following  sections. 


6.3  Internal  Concurrency  Policy 

The  internal  concurrency  policy  of  a  class  sets  the  upper  bound  on  the  extent  of  interleaving  for  the 
methods  of  a  class  and  its  subclasses.  In  other  words,  the  internal  concurrency  policy  is  an  approx¬ 
imation  of  the  representation  invariants  that  define  safe  vs.  unsafe  concurrency  for  a  class  imple¬ 
mentation.  Its  focus  is  on  the  maintenance  of  the  integrity  of  the  shared  state  by  the  implementation 
and  specifically  not  on  the  client-side  correct  use  of  the  class.  Internal  policy  expresses  constraints 

2In  an  earlier  presentation  [GS02],  we  refer  to  these  uses  as  guiding  and  client  policy,  respectively. 
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but  not  the  mechanisms  used  to  prevent  interleaving,  which  may  be  resource-  or  client-side.  An 
implementation  could  use  any  of  the  following  mechanisms,  for  example:  lock-based  critical  sec¬ 
tions,  thread-local  usage,  immutable  encapsulations,  enforcement  of  object  protocols,  and  avoiding 
the  need  for  sharing  through  deep  copying.  A  pair  of  method  implementations  may  have  both  safe 
and  unsafe  interleavings.  A  method-level  boolean  formulation  of  internal  policy  cannot  capture  this 
distinction,  and  thus  two  methods  must  not  be  allowed  to  interleave  if  any  of  their  interleavings  is 
unsafe. 

The  internal  concurrency  policy  for  a  class  is  captured  in  a  separate  design  document  linked 
with  the  class  it  describes.  An  implementation  can  be  checked  to  verify  that  the  internal  concurrency 
policy  is  respected.  The  checks  vary  based  on  the  coordination  techniques  used.  For  example,  an 
analysis  based  on  locks  actually  acquired  by  the  implementation,  and  assumed  to  be  acquired  by 
clients,  can  provide  assurance  that  certain  interleavings  cannot  occur. 

In  the  absence  of  explicit  representation  invariants,  internal  concurrency  policy  is  a  design  deci¬ 
sion  and  so  must  be  trusted.  While  techniques  such  as  those  of  [OG76,  Lam80]  may  help  verify  the 
appropriateness  of  an  internal  policy  with  respect  to  explicit  representation  invariants,  our  experi¬ 
ence  in  multiple  case  studies  is  that  informal  reasoning  (such  as  performed  below)  is  often  sufficient. 
Tools  can  help  with  this  process,  for  example,  by  presenting  to  the  programmer  the  different  inter¬ 
leavings  that  must  be  considered. 

6.3.1  An  Example 

We  now  consider  as  an  example  the  internal  concurrency  policy  for  the  class  BoundedFlFO,  shown 
in  Figure  6.3.  To  reduce  combinatorics,  the  methods  getMaxSize,  isFull,  wasFull,  wasEmpty, 
and  length  have  been  aggregated  into  the  set  Inf  oMethods  because  they  all  have  the  same  policy 
properties.  The  “S”  for  infoMethods  x  infoMethods  means  that  any  pair  in  the  Cartesian 
product  is  safe,  where  safe  means  that  their  concurrent  execution  preserves  the  state’s  integrity. 
Some  of  the  informal  reasoning  based  on  the  implementation  of  BoundedFlFO  used  to  develop  this 
policy  is  as  follows: 

•  Method  get  cannot  be  allowed  to  interleave  with  itself  because  it  could  result  in  both  calls  to 
get  returning  the  same  element.  Referring  to  Figure  1.2,  this  could  happen  if  a  second  thread 
began  to  execute  get  after  the  first  thread  executed  through  line  15. 

•  Method  put  cannot  be  allowed  to  interleave  with  itself  because  it  could  result  in  two  events 
being  stored  in  the  same  location  in  the  underlying  array,  causing  one  of  the  events  to  be  lost. 
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InfoMethods  =  {  getMaxSize,  length,  wasEmpty,  wasFull,  isFull  } 


Figure  6.3:  The  internal  concurrency  policy  for  BoundedFlFO.  An  “S”  indicates  allowable  safe, 
i.e.,  invariant-preserving,  interleaving;  “x”  that  interleaving  is  unsafe  and  disallowed. 


This  could  happen  if  a  second  thread  began  to  execute  put  after  the  first  thread  had  executed 
through  line  24. 

•  Methods  get  and  put  can  be  allowed  to  interleave  with  each  other.  The  predicate  first  == 
next  is  only  true  when  the  FIFO  is  full  or  empty,  in  which  cases  put  or  get,  respectively, 
will  execute  without  accessing  the  contents  of  the  array.  Thus  it  can  never  be  the  case  that 
two  threads  try  to  access  the  same  element  of  the  array  referenced  by  buf .  In  practice  this 
concurrency  is  hard  to  exploit  because  of  the  synchronization  required  to  access  the  shared 
state  and  the  exclusions  required  to  prevent  get  and  put  from  interleaving  with  themselves. 
Because  of  this  difficulty,  we  make  the  design  decision  that  the  internal  policy  should  prevent 
the  interleaving. 

•  The  InfoMethods  set  can  clearly  be  allowed  to  interleave  with  itself  because  all  the  methods 
only  read  state. 

There  are  other  “bad”  results  that  can  happen  as  a  result  of  these  interleavings,  but  these  observations 
are  sufficient  to  prevent  them  as  well  as  those  explicitly  identified. 

6.3.2  Internal  Policy  and  Implementation 

The  reasoning  used  to  develop  the  internal  concurrency  policy  is  necessarily  informed  by  the  im¬ 
plementation  of  the  class,  and,  as  we  see  in  Section  6.5,  by  the  external  concurrency  policy  of 
referenced  classes.  The  purpose  of  the  internal  policy  is  to  describe  what  interleavings  the  imple¬ 
mentation  of  the  class,  where  implementation  includes  constraints  placed  on  clients  of  the  class, 
must  not  allow  to  be  possible.  If  any  one  of  the  interleavings  is  allowed  by  the  implementation, 
then  it  would  be  possible  for  the  representation  invariants  of  the  class  to  be  violated.  This  implies 
that  the  internal  policy  must  actually  be  developed  with  respect  to  some  potentially  non-thread-safe 
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version  of  the  class.  This  is  why  the  above  reasoning  uses  a  version  of  BoundedFlFO  that  does 
not  contain  lock  annotations.  An  internal  policy  developed  with  respect  to  the  protected  version 
of  the  class,  as  in  Figure  5.4,  would  in  fact  be  fully  permissive  because  all  of  the  methods  are  al¬ 
ready  prevented  from  interleaving  with  each  other.  Section  8.3.3  demonstrates  the  development  of 
a  non-trivial  internal  policy  from  code  that  contains  region-based  critical  sections. 

It  is  sometimes  necessary  to  introduce  a  new  lock  for  the  purpose  of  enforcing  policy  decisions. 
The  lock  represented  by  gsLock  in  Figure  6. 1  is  an  example  of  such  a  lock.  We  call  a  lock  used  for 
this  purpose  a  policy  lock  and  do  not  associate  it  with  a  region.  The  programmer  may  document  the 
intent  that  a  lock  is  a  policy  lock  using  the  class  annotation 

@policyLock  lockName  is  representation 

This  is  basically  the  same  as  a  @lock  annotation  but  without  the  region  association.  Currently  there 
arc  no  policy-related  analyses  that  take  direct  advantage  of  this  annotation.  The  lock  analyses  de¬ 
scribed  in  Section  5.6  use  this  annotation  to  support  lock  identification.  This  prevents  “unknown 
lock”  warnings  from  being  generated  when  a  synchronized  block  acquiring  a  policy  lock  is  en¬ 
countered.  Section  7.6  gives  an  example  of  using  a  @policyLock  annotation. 


6.4  External  Policy 

The  responsibility  for  preventing  unsafe  interleavings  may  be  shared  among  a  resource  and  its 
clients.  That  is,  the  implementation  of  the  resource  may  permit  concurrency  that  appeal's  “unsafe” 
with  respect  to  the  internal  policy  as  long  as  clients  can  be  assured  not  to  exploit  it.  The  external 
policy  of  a  class  specifies  pairs  of  methods  that  clients  of  the  class  are  and  are  not  allowed  to  invoke 
concurrently,  constraining  the  design  decisions  of  clients.  Adding  the  following  annotation  to  the 
implementation  of  a  method  m 

@saf  eWith  method  \ methodn 

declares  that  methods  m,  methodi, methodn  may  be  invoked  concurrently  by  clients.  The  name 
of  a  method  set  may  be  used  in  a  @saf  eWith  annotation  to  refer  to  all  the  methods  in  the  set.  To  be 
compatible  with  inheritance,  method  pairs  not  mentioned  in  @saf  eWith  annotations  are  assumed 
to  be  unsafe :  existing  assurances  are  not  compromised  because  unknown  methods  of  subclasses  are 
assumed  to  interfere  with  known  methods.  Subclasses  may  declare  newly  introduced  methods  to  be 
@saf  eWith  inherited  methods  and  may  also  redeclare  as  safe  method  pairs  previously  asserted  to 
be  interfering. 
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The  external  policy  thus  describes  to  clients  of  a  class  which  potentially  unsafe  method  inter¬ 
actions  they  must  avoid.  That  is,  if  two  methods  are  not  @saf  eWith  each  other,  then  a  client  that 
allows  them  to  be  invoked  concurrently  could  cause  the  representation  invariants  of  the  class  to  be 
violated.  Pairs  of  methods  that  arc  @safeWith  each  other  arc  only  guaranteed  to  not  cause  the 
class’s  representation  invariants  to  be  violated.  They  specifically  arc  not  guaranteed  to  actually  ex¬ 
ecute  interleaved;  that  is  they  may  execute  serialized  even  if  they  are  invoked  concurrently.  For 
example,  a  class  implemented  as  a  monitor  takes  full  responsibility  for  protecting  itself  and  thus  has 
an  external  policy  declaring  all  pairs  of  methods  as  safe.  External  policy  is  a  contract,  in  that  its 
safety  guarantees  need  to  persist  as  a  class  evolves  and  is  subclassed.  From  the  standpoint  of  design, 
this  implies  that  the  design  of  annotations  must  not  be  predicated  entirely  on  the  particulars  of  an 
implementation,  but  also  on  potential  evolution  trajectories.  The  external  policy  clearly  must  not  be 
more  permissive  than  the  internal  policy. 

A  potential  race  condition  exists  if  a  conservative  analysis  cannot  assure  consistent  regard  for 
the  policy,  i.e.,  that  unsafe  method  pairs  are  not  used  concurrently  by  a  client.  The  exact  analyses 
necessary  vary  with  available  coordination  techniques.  Currently  we  arc  developing  an  analysis 
based  on  tracking  locks.  Our  relatively  strong  restrictions  on  lock  references  make  this  an  easier 
analysis  than  general  aliasing,  for  example. 

6.4.1  External  Policy  and  Object  Composition 

For  the  purposes  of  analyzing  a  single  client,  the  external  policy  alone  defines  the  contract  for  as¬ 
suring  correct  usage — there  is  no  need  to  examine  the  internal  policy  or  other  annotations  on  the 
resource.  In  the  absence  of  overall  guidance  on  how  the  external  policy  is  to  be  enforced,  how¬ 
ever,  two  different  clients — separately  assured — may  use  different  and  incompatible  techniques.  A 
system  that  simultaneously  used  both  clients  could  be  unsafe  even  though  both  appear-  to  be  individ¬ 
ually  assured  safe.  Focking  annotations  and  uniqueness  annotations  ameliorate  this  composability 
problem.  Focking  preconditions,  via  @requiresLock  annotations,  help  document  design  intent  of 
how  the  external  policy  is  to  be  met.  If  an  object  whose  client  is  responsible  for  enforcing  policy 
is  uniquely  referenced  by  its  client,  then  the  client  may  use  any  technique  to  enforce  the  object’s 
concurrency  policy  because  no  other  clients  can  exist. 

As  an  example,  we  consider  the  case  of  BoundedFIFO  and  a  client  class  BlockingFIFO, 
based  on  the  canonical  clients  of  Figure  5.2,  that  wraps  a  BoundedFIFO  instance  to  produce  a 
blocking  FIFO  implementation.  Figures  6.4  shows  BoundedFIFO  annotated  with  external  pol¬ 
icy  annotations,  among  others;  BlockingFIFO  annotated  with  external  policy  is  shown  in  Fig- 
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1  /** 

2  *  @methodSet  InfoMethods  =  getMaxSize,  length,  wasEmpty,  wasFull,  isFull 

3  *  @methodSet  calleeLocked  =  get,  put,  InfoMethods 

4  *  @lock  BufLock  is  this  protects  Instance 

5  *  @set  InfoMethods  reads  Instance 

6  *  @set  calleeLocked  requiresLock  BufLock 

7  *  @set  calleeLocked  safeWith  InfoMethods  */ 

8  public  class  BoundedFIFO  {  ... 

9  /**  Returns  <code>null</code>  if  empty. 

10  *  @writes  Instance  */ 

11  public  LoggingEvent  get ( )  {  ...  } 

12 

13  /**  If  full,  then  the  event  is  silently  dropped. 

14  *  @writes  Instance  */ 

15  public  void  put (LoggingEvent  o)  {  ...  } 

16 

17  /**  Get  the  capacity  of  the  buffer.  */ 

18  public  int  getMaxSizeO  {  ...  } 

19 

20  /**  Get  the  number  of  elements  in  the  buffer.  */ 

21  public  int  length  ()  {  ...  } 

22 

23  /**  Returns  <code>true</code>  if  the  buffer  was  empty 

24  *  before  last  put  operation.  */ 

25  public  boolean  wasEmpty  ()  {  ...  } 

26 

27  /**  Returns  <code>true</code>  if  the  buffer  was  full 

28  *  before  the  last  get  operation.  */ 

29  public  boolean  wasFullO  {  ...  } 

30 

31  /**  Is  the  buffer  full?  */ 

32  public  boolean  isFullO  {  ...  } 

33  } 


Figure  6.4:  Class  BoundedFIFO  with  external  concurrency  policy  annotations. 


ure  6.5.  The  convention  of  BoundedFIFO  is  that  clients  are  responsible  for  coordinating  their  use 
of  BoundedFIFO  instances:  the  external  policy  of  BoundedFIFO  is  therefore  identical  to  its  inter¬ 
nal  policy.  In  addition,  the  @requiresLock  annotations  on  its  methods  describe  the  mechanism 
through  which  clients  should  coordinate  their  actions.  This  insures,  for  example,  that  the  canonical 
clients  of  Figure  5.2  both  use  the  same  coordination  technique,  avoiding  the  problem  mentioned 
above. 

The  external  policy  for  BlockingFlFO,  on  the  other  hand,  is  fully  permissive.  This  reflects 
the  implementation,  in  which  synchronization  on  fifo — in  compliance  with  the  external  pol¬ 
icy  and  locking  annotations  of  BoundedFIFO — already  prevents  the  proscribed  interleavings  of 
both  BoundedFIFO  and  BlockingFlFO.  Class  BlockingFlFO  guarantees  this  to  its  own  clients 
through  its  own  external  policy,  expressed  via  @safeWith  annotations.  We  note,  however,  that 
while  length  is  safe  with  put  and  get,  the  sensible  use  of  length  in  conjunction  with  either  get 
or  put  is  in  the  domain  of  the  concurrency  policies  of  the  clients  of  BlockingFlFO. 
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/**  @methodSet  WrappedFIFO  =  put,  get,  length  */ 

public  class  BlockingFIFO  { 

private  final  BoundedFIFO  fifo; 

public  BlockingFIFO ( int  size)  {  fifo  =  new  BoundedFIFO (size) ;  } 

/**  @safeWith  WrappedFIFO  */ 

public  void  put (LoggingEvent  e)  { 
synchronized ( fifo)  { 
while ( fifo . isFull () )  { 

try  {  fifo.waitO;  }  catch  (InterruptedException  ie)  {  } 

} 

fifo . put  (e) ; 

if (fifo . wasEmpty ( ) )  fifo . notify ( ) ; 


/**  @safeWith  WrappedFIFO  */ 

public  LoggingEvent  get ( )  { 
synchronized ( fifo)  { 

LoggingEvent  e ; 

while ( fifo . length ( )  ==  0)  { 

try  {  fifo.waitO;  }  catch  (InterruptedException  ie)  {  } 

} 

e  =  fifo . get ( ) ; 

if ( f if o . wasFull ( ) )  f if o . notify ( ) ; 
return  e; 


/**  @safeWith  WrappedFIFO  */ 

public  int  length ()  { 

synchronized ( fifo)  {  return  f if o . length () ;  } 


Figure  6.5:  BlockingFIFO  class  as  a  client  of  BoundedFIFO. 


6.4.2  Self-Protected  Objects 

It  is  convenient  to  declare  that  objects  of  a  particular  class  take  sole  responsibility  for  protecting 
their  invariants.  Such  objects  arc  traditionally  what  one  expects  when  thinking  of  a  “thread-safe” 
object.  They  have  the  advantage  that  clients  of  the  object  do  not  need  to  do  anything  special  before 
invoking  methods  on  them.  The  class  annotation 

@self Protected 

documents  the  design  intent  that  a  class,  and  its  subclasses,  take  full  responsibility  for  protecting 
themselves.  It  is  like  a  fully  permissive  external  policy,  every  method  is  safe  with  every  other 
method,  except  that  it  additionally  requires  that  any  method  added  by  a  subclass  is  also  safe  with  all 
other  methods. 

We  emphasize  again  that  the  techniques  used  by  a  class  to  be  compliant  with  its  declared  external 
policy  arc  unspecified.  In  general,  we  envision  this  annotation  to  be  used  on  classes  that  implement 
either  (1)  immutable  objects  or  (2)  monitors.  The  analyses  that  would  be  used  to  verify  policy 
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compliance  in  these  two  case  arc  different,  and  the  @self Protected  annotation  by  itself  does  not 
provide  enough  information  to  know  which  technique  is  being  used.  It  has  the  advantage,  however, 
of  being  abstract,  and  thus,  for  example,  an  interface  can  be  annotated  as  being  @self  Protected 
and  have  multiple  implementations,  some  of  which  are  immutable  and  some  of  which  arc  monitors. 

In  Parameterized  RaceFreeJava  [BR01],  a  class  may  be  “self-synchronized.”  Such  classes 
implement  objects  that  always  own  themselves,  which  in  the  idiom  of  their  system  means  that 
instances  of  the  class  must  always  lock  on  themselves  to  protect  their  state.  This  is  more  specific 
than  what  our  @self  Protected  annotation  is  declaring;  a  self-synchronized  class  is  one  way  in 
which  a  @self  Protected  class  could  be  implemented. 


6.5  A  Policy  Mismatch  Error 

We  now  give  an  example  from  Log4j  version  1.1  b5  in  which  the  external  policy  of  a  provider 
class  is  not  followed  by  the  implementations  of  its  clients.  This  “policy  mismatch”  creates  several 
sources  of  null-pointer  and  index-out-of-bounds  exceptions,  as  well  as  enabling  a  violation  of  an 
internal  object  protocol  [GreOl].  These  exceptions  can  cause  the  program  being  logged  to  terminate 
prematurely  or  portions  of  the  logging  functionality  to  misbehave. 

The  Log4j  library  is  introduced  in  Section  1.3;  here  we  describe  additional  details  relevant 
to  this  example.  Logging-event  sources  implement  the  AppenderAttachable  interface,  shown  in 
Figure  6.6;  Appender  objects  are  chained  together  by  attaching  to  classes  that  implement  Append¬ 
erAttachable.  The  library  provides  two  classes  that  implement  the  interface.  To  avoid  duplicat¬ 
ing  the  implementation,  the  core  functionality  of  managing  event  listeners  is  implemented  by  the 
class  AppenderAttachablelmpl,  partially  shown  in  Figure  6.7.  This  class  does  not  make  use 
of  synchronization.  The  AppenderAttachable  interface  is  implemented  by  classes  Category 
and  AsyncAppender,  neither  shown,  whose  instances  each  have  their  own  unaliased  Appender¬ 
Attachablelmpl  instance  to  which  they  delegate  calls. 

Unlike  the  case  of  BoundedFlFO,  which  also  originates  from  the  Log4j  library,  there  is  no 
discernible  convention  on  client  synchronization,  even  though  it  is  clearly  the  responsibility  of  the 
clients  of  AppenderAttachablelmpl  to  protect  it  from  concurrent  access.  In  Category  and 
AsyncAppender,  the  methods  addAppender,  removeAppender (String) ,  removeAppend- 
er  (Appender) ,  and  removeAl  1  Appender s  are  synchronized.  The  uses  of  method  append- 
LoopOnAppenders,  a  method  which  is  not  part  of  the  AppenderAttachable  interface,  are  syn¬ 
chronized  within  Category,  but  not  in  AsyncAppender.  This  synchronization  is  not  sufficient  to 
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1  public  interface  AppenderAttachable  { 

2  /**  Add  an  appender.  */ 

3  public  void  addAppender (Appender  newAppender); 

4 

5  /**  Get  all  previously  added  appenders  as  an  Enumeration.  */ 

6  public  Enumeration  getAllAppenders ( ) ; 

7 

8  /**  Get  an  appender  by  name.  */ 

9  public  Appender  getAppender (String  name); 

10 

11  /**  Remove  all  previously  added  appenders.  */ 

12  void  removeAllAppenders ( ) ; 

13 

14  /**  Remove  the  appender  passed  as  parameter  from  the  list 

15  *  of  appenders.  */ 

16  void  removeAppender (Appender  appender); 

17 

18  /**  Remove  the  appender  with  the  name  passed  as  parameter  from 

19  *  the  list  of  appenders.  */ 

20  void  removeAppender (String  name); 

21  } 


Figure  6.6:  Log4j’s  AppenderAttachable  interface. 


1  public  class  AppenderAttachablelmpl  implements  AppenderAttachable  { 

2  protected  Vector  appenderList ; 

3 

4  public  void  addAppender (Appender  newAppender)  { 

5  if (newAppender  ==  null)  return; 

6  if (appenderList  ==  null)  appenderList  =  new  Vector (1) ; 

7  if ( ! appenderList . contains (newAppender) )  { 

8  appenderList . addElement (newAppender) ;  } 

9  } 

10 

11  /**  Call  the  doAppend  method  on  all  attached  appenders.  */ 

12  public  int  appendLoopOnAppenders (LoggingEvent  event)  { 

13  int  size  =  0; 

14  Appender  appender; 

15 

16  if  (appenderList  !=  null)  { 

17  size  =  appenderList .  size  ()  ; 

18  for  (int  i  =  0;  i  <  size;  i++)  { 

19  appender  =  (Appender)  appenderList . elementAt (i) ; 

20  appender . doAppend ( event ) ; 


23  return  size; 

24  } 

25 

26  public  void  removeAppender (Appender  appender)  { 

27  if (appender  ==  null  | |  appenderList  ==  null)  return; 

28  appenderList . removeElement (appender) ; 

29  } 

30  ... 

31  } 


Figure  6.7:  A  portion  of  the  implementation  of  Log4j's  AppenderAttachablelmpl  class. 
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Figure  6.8:  (a)  Monitor-like  and  (b)  reader-writer  external  policies  for  AppenderAttachable- 
Impl  expressed  using  regions  and  effects,  respectively.  “S”  indicates  concurrent  execution  is  safe; 
“x”  indicates  concurrent  execution  is  prohibited. 


prevent  null-pointer  and  index-out-of-bounds  exceptions  during  concurrent  use,  as  will  become  ap¬ 
parent  when  we  examine  the  external  concurrency  policy  we  inferred  for AppenderAttachable- 
Impl.  First  we  infer  a  correct  external  policy,  then  we  illustrate  how  it  is  violated,  and  finally  we 
suggest  how  analyses  might  detect  the  policy  violations. 

6.5.1  External  Policies  for  AppenderAttachablelmpl 

Generally  speaking,  the  most  conservative  external  policy  is  a  policy  that  does  not  allow  the  client 
to  execute  any  pair  of  methods  concurrently.  This  is  most  concisely  recorded  using  the  region- 
based  policy  shown  in  Figure  6.8a:  any  two  methods  that  access  region  Instance  of  the  same 
AppenderAttachablelmpl  object  are  prevented  from  executing  concurrently.  An  example  of  a 
policy  that  allows  more  concurrency  in  the  usage  of  the  class  is  a  reader-writer  policy.  This  is  most 
naturally  recorded  using  an  effects-based  policy  description,  shown  in  Figure  6.8b,  differentiating 
methods  based  on  their  effects  on  an  AppenderAttachablelmpl  object.  Both  of  these  policies 
could  also  be  more  verbosely  expressed  using  method  sets  or  a  purely  method-based  policy  matrix. 
In  the  general  case,  region-  and  effects-based  policy  descriptions  have  the  advantage  that  they  are 
easy  and  concise  to  express  and  they  often  can  be  automatically  produced  based  on  an  analysis  of 
the  effects  of  the  class  implementation. 

Returning  to  our  example,  the  most  liberal  external  concurrency  policy  for  AppenderAttach¬ 
ablelmpl  is  shown  in  Figure  6.9.  This  policy  is  identical  to  the  class’s  internal  concurrency  policy, 
and  is  more  permissive  than  the  reader-writer  policy;  differences  from  the  reader-writer  policy 
are  in  bold.  Three  of  the  allowable  interleavings,  marked  by  asterisks,  arc  safe  because  their  only 
possible  interactions  arc  through  the  Vector  referenced  by  appenderList,  and  the  external  pol¬ 
icy  of  Vector,  were  the  JDK  appropriately  annotated,  indicates  that  any  one  of  its  methods  is 
@safeWith  any  other.  An  analysis  informed  by  the  effects  of  AppenderAttachablelmpl  and 
the  external  policy  of  Vector  could  deduce  the  safety  of  these  methods.  The  other  five  safe  inter- 
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Figure  6.9:  The  most  liberal  external  concurrency  policy  for  AppenderAttachablelmpl.  A  bold 
“S”  indicates  differences  from  the  reader-writer  policy.  Pairs  marked*  arc  safe  due  to  the  underlying 
Vector. _ 


leavings  require  reasoning  about  changes  to  the  fields  of  the  object  itself.  Let  us  review  some  of  the 
reasoning  for  allowing  and  disallowing  interleaving  with  method  addAppender;  see  Figure  6.7. 

•  We  do  not  declare  addAppender  to  be  @saf  eWith  addAppender.  Both  executions  could 
observe  appenderList  to  be  null,  in  which  case  both  would  assign  a  new  Vector  to  the 
field:  one  of  the  added  appenders  will  be  lost. 

•  We  declare  addAppender  to  be  @safeWith  appendLoopOnAppenders.  In  developing 
this  policy  we  consider  two  interactions.  (1)  addAppender  can  assign  a  new  Vector  to 
appenderList  if  there  is  no  existing  vector.  But  appendLoopOnAppenders  terminates 
when  appenderList  is  null.  (2)  addAppender  can  add  to  the  vector  once  it  is  present. 
But  appendLoopOnAppenders  invokes  appenderList  .size  before  its  loop,  so  iterations 
will  stop  before  any  newly  added  element  is  reached.  In  both  cases,  the  interleaved  methods 
execute  as  if  appendLoopOnAppenders  executed  before  addAppender.  Thus  this  pair  can 
be  marked  as  safe  in  the  external  policy. 

•  We  do  not  declare  the  Appender-taking  version  of  removeAppender  to  be  @safeWith 
appendLoopOnAppenders.  If  removeAppender  removes  an  element  from  the  list  after 
appendLoopOnAppenders  has  read  the  size  of  the  list,  then  an  index-out-of-bounds  ex¬ 
ception  can  result  because  appendLoopOnAppenders  will  iterate  past  the  end  of  the  list 
of  appenders.  This  is  an  example  of  how  even  though  the  methods  of  a  class,  in  this  case 
Vector,  may  be  @saf  eWith  each  other,  their  concurrent  use  must  still  be  coordinated  at  a 
higher  level  to  preserve  higher-level  invariants. 

•  We  declare  removeAppender  (Appender)  to  be  @saf  eWith  itself  because  the  the  concur- 
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Figure  6.10:  The  policy  enforced  by  clients  of  AppenderAttachablelmpl.  Boxes  indicate  where 
the  enforced  policy  is  different  from  the  external  policy. 


rency  policy  for  Vector  indicates  that  removeElement  is  @saf  eWith  itself. 

6.5.2  Detecting  the  Mismatch 

Failure  to  use  enough  synchronization  within  Category  and  AsyncAppender  enables  seven  inter¬ 
leavings  disallowed  by  our  inferred  policy  and  could  thus  cause  unwanted  exceptions.  The  policy 
enforced  by  these  two  classes  in  their  usage  of  an  instance  of  AppenderAttachablelmpl  is  shown 
in  Figure  6.10.  Differences  from  the  external  policy  are  boxed;  in  particular,  the  seven  occurrences 
of  an  [s]  indicate  errors  in  the  implementations  of  the  clients.  A  static  analysis  can  detect  the  policy 
violations  if  the  following  annotations  are  added  (1)  an  external  policy  for  AppenderAttachable¬ 
lmpl,  and  (2)  uniqueness  of  the  delegate  references  in  Category  and  AsyncAppender.  Clearly 
the  external  policy  must  be  specified  before  it  can  be  enforced.  Because  AppenderAttachable¬ 
lmpl  has  no  locking  annotations,  it  does  not  provide  any  hints  regarding  how  clients  should  enforce 
its  external  policy.  By  annotating  that  the  delegate  references  are  @unshared,  we  insure  that  those 
instances  will  have  exactly  one  client,  and  thus  the  client  is  free  to  protect  the  delegate  in  any  man¬ 
ner  it  chooses.  In  this  particular  case,  both  Category  and  AsyncAppender  lock  themselves  to 
protect  the  delegate. 

A  static  analysis  based  on  extant  locking  to  enforce  the  external  policy  would  proceed  by  iden¬ 
tifying  all  the  locks  that  must  be  held  at  each  site  where  a  method  on  the  AppenderAttachable¬ 
lmpl  instance  is  called.  Let  m*  be  the  set  of  locks  that  must  be  held  at  call  site  i  of  method  m. 
Then  for  each  pair  of  methods  (rri.  n)  that  the  external  policy  does  not  declare  as  safe,  such  that  m 
has  call  sites  drawn  from  set  p  and  n  has  call  sites  drawn  from  set  q,  the  client  correctly  enforces 
the  policy  pair  if  (Pliep  m* )  ^  (flje?  ni)  i ^  That  is,  there  exists  a  lock  that  must  always  be  held 
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whenever  m  is  called  and  whenever  n  is  called. 

We  omit  the  details  of  how  the  policy  mismatch  can  be  fixed;  see  [GreOl].  We  do  note,  how¬ 
ever  that  it  is  nontrivial  to  implement  a  general-purpose  client  that  is  not  more  conservative  than 
the  policy  in  Figure  6.9.  There  is  likely  to  be  little  performance  benefit,  because  the  overhead  of 
synchronization  is  likely  to  outweigh  the  benefits  of  concurrency.  The  benefits  of  such  a  liberal 
external  policy,  however,  stem  from  the  documentation  of  design  intent.  By  documenting  external 
policy,  clients  arc  given  more  information  about  how  the  class  is  intended  to  be  used.  For  example, 
were  Buf  f  eredlnputStream  given  a  policy  that  indicated  that  read  and  close  were  not  safe  to 
invoke  concurrently,  the  whole  scenario  described  in  Section  1.4  would  be  irrelevant. 


6.6  Policy  Representation  Revisited 

The  method-based  approach  to  expressing  policy  has  several  problems.  An  obvious  problem  is  that 
it  does  not  scale  well.  For  classes  with  more  than  a  handful  of  methods,  expressing  the  policy  is 
likely  to  be  burdensome.  Considering  the  method  interactions  is  more  burdensome  still.  The  com¬ 
binatorics  of  policy  expression  can  be  reduced  by  instead  expressing  policy  in  terms  of  interactions 
over  regions,  as  briefly  explored  in  Section  6.5.  There  is  an  obvious  trade-off  between  conciseness 
of  expression  and  flexibility  in  expressed  policies. 

A  second  problem  with  method-based  policy  expression,  that  can  also  be  addressed  by  switching 
to  a  region-based  policy,  is  scoping  the  concurrency  policy.  Many  cases  exist  where  the  scope  of  a 
policy  must  go  beyond  a  single  class  and  its  subclasses.  For  example,  classes  collaborating  via  an 
enumerator  may  require  policy  to  be  expressed  at  the  level  of  the  classes  involved.  In  Appender- 
Attachablelmpl,  the  enumeration-returning  method  getAHAppenders  is  @saf  eWith  various 
mutator  methods  of  the  class,  but  the  resulting  enumeration  object  is  not  because  it  is  an  unprotected 
access  path  to  the  underlying  state  of  the  Vector.  Specifying  policy  in  terms  of  regions  enables  the 
capture  of  all  methods  that  can  affect  those  regions,  and  thus  captures  access  paths  via  enumerations, 
for  example. 


6.7  Related  Work 

We  believe  that  our  presentation  of  concurrency  policy  is  a  novel  approach  to  the  specification  and 
maintenance  of  unstated  representation  invariants.  In  particular,  none  of  the  tools  discussed  in  pre¬ 
vious  chapters,  i.e.,  ESC/Java  [FLL+02],  RaceFreeJava  [FFOO],  Parameterized  RaceFreeJava 
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[BR01],  and  Guava  [BSTOO],  support  the  description  of  concurrency  policy. 

Noble.  Holmes  and  Potter  describe  an  “algebra  of  exclusion”  for  reasoning  about  exclusion  in 
composite  objects  [NHPOO].  The  underlying  semantics  of  their  algebra  is  identical  to  that  of  our 
method-based  concurrency  policy:  pairs  of  methods  whose  executions  must  exclude  each  other. 
Their  algebra  represents  the  matrix  symbolically.  A  difference  is  that  they  arc  not  concerned  with 
relating  the  matrix  to  implementation,  rather  they  are  concerned  with  relating  the  matrix  to  the  archi¬ 
tecture  of  a  system  of  objects.  They  envision  that  an  implementation  is  derived  from  unsynchronized 
code  and  a  specification  of  the  exclusion  constraints  via  an  aspect-oriented  programming  system. 
They  are  primarily  concerned  with  being  able  to  reason  about  two  things:  (1)  that  the  exclusion  con¬ 
straints  of  a  composite  object  satisfy  those  of  its  delegate  objects,  and  that  therefore  the  aggregated 
objects  do  not  require  exclusion  in  their  implementation;  and  (2)  that  the  exclusion  implemented 
by  delegate  objects  is  sufficient  to  satisfy  the  constraints  of  the  composite  object.  Because  they 
arc  not  focused  on  implementation,  there  is  no  assurance  that  implementations  actually  implement 
the  exclusions,  or  that  aggregated  delegate  objects  arc  actually  properly  contained  to  satisfy  the  as¬ 
sumptions  of  their  logic.  In  this  regard,  their  work  complements  ours:  while  our  work  is  concerned 
with  the  assurance  that  an  implementation  is  consistent  with  its  policy,  their  work  is  concerned  with 
assuring  that  the  interaction  of  the  policies  of  cooperating  objects  produces  the  desired  effects. 

Several  languages  contain  non-lock-based  syntactic  constructs  for  implementing  mutual  exclu¬ 
sion  that  superficially  resemble  concurrency  policy.  In  Path  Pascal  [CH74],  class-level  path  expres¬ 
sions  specify  both  object  protocol  and  concurrency  constraints.  In  a  language  proposed  by  Andrews 
and  McGraw  [AM77]  each  method  is  annotated  with  those  methods  that  may  execute  concurrently 
with  it  (a.k.a.  compatibilities).  CEiffel  [Loh93],  a  multi-threaded  dialect  of  Eiffel,  uses  a  similar 
annotation.  Subclasses  may,  however,  arbitrarily  alter  the  compatibilities  of  a  method,  and  abstract 
methods  may  not  specify  any  compatibilities:  we  conclude  that  these  annotations  are  primarily  for 
implementing  synchronization  rather  than  for  describing  policy. 

Lucassen  extends  his  effects  system  with  monitor-call  effects  “to  give  the  programmer  some 
control  over  the  way  in  which  computations  are  interleaved”  [Luc87].  All  monitor-call  effects  are 
defined  to  interfere  with  each  other.  Described  as  an  external  concurrency  policy,  the  policy  would 
be  at  the  system  granularity  and  all  methods  of  all  monitors  would  exclude  each  other. 

Schwarz  and  Spector  consider  transactions  on  abstract  data  types  [SS84].  Their  technique  is 
similar  to  our  policy  in  that  their  motivation  is  to  be  able  to  reason  about  the  interactions  of  opera¬ 
tions  on  abstract  types. 

Flanagan  and  Qadeer  have  developed  a  type  system  for  specifying  and  checking  atomicity  prop- 


6.7.  RELATED  WORK 


127 


erties  [FQ03b]  and  have  applied  it  to  Java  [FQ03a].  This  system  is  an  extension  of  the  race-free  type 
system  used  by  RaceFreeJava,  and  is  meant  to  solve  the  problem  that  race-freedom  as  defined 
by  their  previous  work  does  not  account  for  the  interleaving  of  critical  sections,  as  discussed  in 
Section  6.1.  Their  type  system  is  based  upon  Lipton’s  theory  of  reduction  [Lip75],  and  categorizes 
expressions  based  on  their  ability  to  interleave  with  the  actions  of  other  threads.  Programmers  must 
type  a  method  with  its  intended  atomicity.  Such  a  type  system  could  be  adapted  for  assuring  that  a 
class  implementation  is  consistent  with  its  internal  concurrency  policy. 


Chapter  7 


Tools 


We  have  implemented  a  prototype  tool  that  embodies  the  analysis  techniques  described  in  previous 
chapters.  Our  experience  with  the  tool  provides  some  preliminary  evidence  of  the  practicability  of 
our  approach  for  ordinary  programmers  on  deadlines.  As  mentioned  throughout,  our  design  deci¬ 
sions  are  fundamentally  influenced  by  the  desire  that  our  approach  be  adoptable  by  working  pro¬ 
grammers.  This  influences  our  approach  to  recording  design  intent.  Specifically,  we  avoid  recording 
explicit  representation  invariants:  we  record  intent  using  annotations  that  describe  models  of  me¬ 
chanical  program  behavior.  These  annotations  arc  intended  to  answer  questions  that  the  programmer 
is  already  thinking  about.  The  design  of  the  tool  is  also  influenced  by  our  focus  on  adoptability.  We 
wish  to  provide  the  programmer  using  our  tool  with  “early  gratification” — some  assurance  should 
be  obtained  with  minimal  or  no  annotation  effort,  and  additional  increments  of  annotation  should  be 
rewarded  with  additional  increments  of  assurance  or  warnings  of  model-code  inconsistencies.  Our 
prototype  tool  thus  supports  an  interactive  and  iterative  assurance  process.  The  programmer  builds 
up  assurance  results  by  gradually  executing  assurance  analyses  and  introducing  annotations.  Thus 
for  our  principle  of  early  gratification  to  be  satisfied,  a  programmer  must  be  rewarded  with  useful 
analysis  results  within  the  first  few  iterations,  and  should  not  have  to  introduce  large  amounts  of 
annotations. 

The  design  of  our  tool  allows  assurance  to  proceed  incrementally  across  the  code  base  and 
across  the  models  of  intent.  Unlike  similar  tools,  such  as  RaceFreeJava  and  Guava,  we  do  not 
require  that  the  entire  program  to  be  assured  thread-safe  at  once,  a  fundamental  obstacle  to  providing 
early  gratification.  These  tools  use  modular  type  systems,  but  the  assumption  is  that  the  whole 
program  is  being  made  thread-safe  at  once.  This  is  evident,  for  example,  by  the  requirement  that 
all  fields  be  associated  with  a  lock,  or  the  assumption  that  any  reference  to  an  object  is  going 
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to  be  a  safe  object.  Such  assumptions  make  it  difficult  to  obtain  meaningful  incremental  results 
because  there  is  no  provision  for  distinguishing  code  that  is  not  yet  annotated  from  code  that  is 
annotated  and  inconsistent  with  its  annotations.  These  approaches  force  the  programmer  to  annotate 
everything  about  every  class  before  meaningful  results  arc  possible.  Our  approach,  on  the  other 
hand,  is  to  consider  annotations  as  specifications  of  models  with  which  source  code  should  be 
consistent.  Additional  annotations  thus  describe  additional  models  of  design  intent.  An  unannotated 
class  is  merely  a  class  that  has  no  models  that  it  should  be  assured  against.  Assurance  of  an  annotated 
class  may  be  compromised  by  the  absence  of  annotation  on  another  class;  we  must  be  careful, 
therefore,  to  place  failure  appropriately  on  the  lack  of  design  information  on  the  unannotated  class, 
as  well  as  not  to  be  report  misleading  results.  Our  tool  thus  reports  a  class  of  messages,  "warnings,” 
that  do  not  indicate  code-model  inconsistency,  but  rather  call  to  the  attention  of  the  programmer 
places  where  additional  assurance  is  probably  possible  if  additional  design  intent  is  specified. 

An  additional  distinguishing  feature  of  our  approach,  and  its  embodiment  in  a  prototype  tool, 
is  that  we  wish  to  go  beyond  “bug  hunting.”  It  is  just  as  important  to  provide  positive  assurance 
that  source  code  is  consistent  with  intent  as  it  is  to  report  the  inconsistencies.  Similar  tools  such 
as  ESC/Java  arc  intended  to  statically  find  errors  that  would  otherwise  only  be  caught  at  runtime, 
if  at  all,  because  their  manifestation  may  be  nondeterministic.  Such  tools,  which  include  model 
checkers,  therefore,  are  only  interested  in  negative  results,  and  are  typically  incapable  of  providing 
explicit  positive  assurance  that  the  program  is  consistent  with  the  specified  model  of  design  intent. 
A  run  with  no  warnings  must  usually  be  interpreted  to  mean  that  the  tool  was  unable  to  find  any 
inconsistencies,  but  cannot  reliably  be  interpreted  to  mean  that  the  model  is  satisfied  by  the  program. 
Our  tool  should  only  be  silent  when  there  are  no  models  are  assure.  Future  work  is  to  provide 
“chains  of  evidence”  that  link  together  expressed  design  intent,  analysis  results,  and  code  segments 
to  document  the  reasoning  behind  each  assurance  result. 

In  what  follows,  we  first  describe  our  prototype  assurance  tool  and  how  it  is  incorporated  into 
the  Eclipse  IDE.  We  then  briefly  discuss  our  framework  for  representing  data  in  general  and  for 
representing  Java  programs  specifically.  This  is  followed  by  a  discussion  of  the  annotations  and 
analyses  supported  by  our  prototype  tool  and  some  notes  on  their  implementation.  This  chapter 
concludes  with  two  examples  of  using  our  prototype  tool  to  assure  the  safety  of  classes  taken  from 
production  Java  code. 


7.1.  THE  FLUID  ECLIPSE  PLUG-INS 
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7.1  The  Fluid  Eclipse  Plug-Ins 

Our  prototype  assurance  tool  is  implemented  as  a  set  of  plug-ins  to  the  open  source  Eclipse)  Inte¬ 
grated  Development  Environment  (IDE).2  Integration  with  an  existing  IDE  allows  our  engineering 
effort  to  be  focused  on  the  implementation  of  our  analysis  and  assurance  infrastructure  rather  than 
the  mundane  tasks  of  maintaining  a  Java  front-end.  Incorporation  within  an  IDE  is  also  important 
pedagogically  because  of  our  desire  that  the  programmer  have  an  incremental  and  iterative  “con¬ 
versation”  with  the  assurance  tool:  to  be  adoptable,  our  tool  must  integrate  well  with  existing  tools 
used  by  a  typical  programmer. 

Figure  7. 1  shows  an  example  of  an  Eclipse  workspace  window  containing  our  tool,  visible  as  the 
“Code  Quality  Advice”  view  below  the  environment’s  standard  Java  editor.  Here,  the  editor  shows 
a  portion  of  a  partially  annotated  version  of  the  BoundedFlFO  class.  Our  assurance  tool  has  been 
run  on  BoundedFlFO .  j  ava  and  the  rest  of  the  “BoundedFlFO  Example”  project  (visible  in  the 
“Package  Explorer”  view  on  the  left).  The  results  arc  shown  sorted  by  issue  in  the  “Code  Quality 
View;”  they  may  also  be  sorted  by  file.  The  presentation  of  assurance  results  is  a  fundamental 
issue  in  the  adoptability  of  our  tool  and  is  on-going  research.  Results  in  our  “Code  Quality  View” 
include: 

•  Positive  assurance  of  model-source  code  consistency.  These  results  arc  marked  by  an  icon 
representing  an  unbroken  chain.  Specifically,  analyses  found  11  call  sites  where  methods 
annotated  with  lock  preconditions  were  called  with  those  preconditions  satisfied,  and  15  field 
accesses  where  the  fields  arc  accessed  with  the  appropriate  lock  held. 

•  Identification  of  model-source  code  inconsistencies,  i.e.,  assurance  failures.  These  results  arc 
marked  by  a  broken  chain  icon.  Here  we  see  that  analysis  is  unable  to  assure  that  nine  field 
accesses  arc  consistent  with  the  annotated  locking  model.  Expanding  the  top-level  node  in  the 
view  reveals  the  specific  accesses  that  may  violate  the  model.  As  expected,  double-clicking 
on  these  results  focuses  the  editor  window  on  the  offending  line  of  source  code. 

•  Warnings  of  missing  intent — also  (unfortunately)  marked  by  a  broken  chain  icon.  In  this 
case,  our  tool  warns  that  there  arc  two  references  to  a  possible  shared  unprotected  object;  see 
Section  5.7.  This  is  distinguished  from  an  assurance  failure  because  no  annotated  model  is 
actually  being  violated. 

Our  prototype  assurance  tool  is  implemented  as  two  Eclipse  plug-ins.  The  Fluid  Plug-in  is 

’http : //www .eclipse.org/ 

2  The  design  and  implementation  of  our  prototype  tool  is  an  on-going  effort  by  all  members  of  the  Fluid  group. 


Figure  7.1:  The  Eclipse  IDE  with  our  prototype  assurance  plug-in.  Our  plug-in  provides  the  “Code  Quality  Advice”  view. 
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Figure  7.2:  Data  flow  in  our  prototype  assurance  tool. 


a  library  of  our  analyses,  data  structures,  and  other  concerns  that  arc  not  handled  by  Eclipse.  It 
also  contains  the  routines  for  converting  from  Eclipse  representations  to  our  own.  This  plug-in 
is  approximately  160,000  lines  of  Java  code  (160kLOC).  It  does  not  define  any  Eclipse  views  or 
other  user-visible  GUI  items.  The  Fluid  Assurance  Plug-in  defines  the  “Code  Quality  View”  and 
provides  the  means  for  an  Eclipse  user  to  run  assurance  analyses  and  interact  with  the  results.  It  is 
relatively  small,  only  several  thousand  lines  of  Java  code.  Eclipse  itself  is  approximately  600kLOC. 
Figure  7.2  shows  the  general  relationship  between  the  two  plug-ins  and  the  Eclipse  environment. 

The  programmer,  i.e.,  the  Eclipse  user,  interacts  with  our  tool  via  the  “Code  Quality  View”  pro¬ 
vided  by  the  Fluid  Assurance  Plug-in.  The  programmer  runs  the  assurance  analyses  by  clicking  on 
the  flashlight  icon  in  the  view’s  toolbar.  This  causes  all  the  Java  source  files  in  all  the  open  projects 
to  be  analyzed.  This  “analyze  everything”  approach  is  an  artifact  of  boot-strapping  the  tool  imple¬ 
mentation.  We  emphasize  that  our  analyses  are  not  interprocedural  or  whole -program:  each  class 
is  analyzed  independently  using  only  the  annotated  interfaces  of  other  classes.  Annotations  serve 
as  outpoints,  enabling  global  analysis  to  be  avoided  and  opaque  components  to  be  integrated  safely, 
contingent  on  the  validity  of  their  annotations.  Eclipse  allows  analyses  to  be  run  automatically  as 
source  code  is  changed;  indeed,  this  is  one  of  the  reasons  we  chose  to  integrate  our  tool  with  Eclipse. 
Using  this  framework  to  drive  our  analyses  is  on-going  work  and  should  enhance  the  usability  and 
adoptability  of  our  tool. 
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More  specifically,  the  Fluid  Assurance  Plug-in  bridges  the  functionality  of  Eclipse  and  the  Fluid 
Plug-in  and  provides  our  tool's  user  interface.  The  Fluid  Assurance  Plug-in  drives  analysis  by 
querying  Eclipse  about  the  workspace  and  obtaining  resource  handles  to  all  the  Java  files  in  the 
workspace.  For  each  Java  file,  the  plug-in  has  Eclipse  parse  it  into  an  abstract  syntax  tree  (AST). 
From  this  AST,  a  parallel  AST  in  our  own  representation  is  created;  Section  7.2  discusses  the  ra¬ 
tionale  for  this.  Each  analysis,  the  code  for  which  resides  in  the  Fluid  plug-in,  is  invoked  on  this 
parallel  AST.  The  implementation  of  our  analyses  and  their  interdependencies  arc  discussed  in  more 
detail  in  Section  7.4.1.  Analysis  results,  i.e.,  positive  assurances,  etc.,  are  reported  back  to  the  Fluid 
Assurance  Plug-in  via  callbacks. 

Several  of  our  analyses  arc  data-flow-based  and  require  control-flow  graphs  (CFGs).  Our 
Fluid  Plug-in  provides  an  infrastructure  for  building  CFGs  from  our  AST  representation;  see  Sec¬ 
tion  7.2.2.  Analysis  also  requires  binding  information,  that  is,  the  binding  of  lexical  names  to  their 
definitions  in  the  AST.  Eclipse  provides  a  basic  binder,  which  we  wrap  in  the  Fluid  Plug-in  (1)  to 
insure  that  binding  results  are  relative  to  our  AST  instead  of  the  the  Eclipse-based  AST,  and  (2)  to 
provide  additional  information  not  directly  available  from  the  Eclipse  binder. 

The  Fluid  Assurance  Plug-in  gathers  analysis  results  via  callbacks  and  displays  the  results  from 
all  the  analyses  in  the  “Code  Quality  View”  as  a  tree.  Currently,  the  results  may  be  displayed 
sorted  by  issue,  as  seen  in  Figure  7.1,  and  by  package  and  class.  The  programmer  may  browse  the 
results;  double-clicking  on  a  particular  issue — positive  or  negative — focuses  the  Eclipse  editor  on 
the  relevant  line  of  code. 


7.2  Representations 

Our  plug-ins  use  many  special  purpose  program  representations  in  parallel  to  those  provided  by 
the  Eclipse  API.  These  data  structures  are  built  on  top  of  a  data  representation  framework  that  we 
call  the  Fluid  Internal  Representation,  or  IR.  This  framework  predates  our  work  with  the  Eclipse 
IDE  and  provides  sophisticated  versioning  and  persistence  features,  that  while  unused  by  the  cur¬ 
rent  prototype  tool,  arc  critical  for  the  project’s  longer  term  goals  of  studying  tools  that  manage 
program  evolution.  Here  we  first  briefly  describe  the  IR  framework,  and  then  describe  the  program 
representations  built  on  top  of  it. 
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7.2.1  The  IR 

The  IR  models  general  purpose  data  using  a  modified  version  of  the  standard  ternary  representation: 
unique  identifiers,  attributes,  and  values.  The  modifications  we  make  include  (1)  ultra-fine  grained 
tree-structured  versioning,  (2)  abstraction  to  structured  entities  such  as  trees  and  directed  graphs, 
and  (3)  persistence.  These  arc  also  several  other  features  not  used  in  this  prototype. 

Our  implementation  represents  the  unique  identifiers  as  objects  that  implement  a  distinguished 
interface,  iRNode,  that  defines  a  small  set  of  operations  for  getting  and  comparing  identity,  and  for 
getting  and  setting  the  value  associated  with  that  identifier  and  a  specific  attribute.  Attributes  arc 
simply  containers  for  values  indexed  by  unique  identifiers,  and  may  optionally  be  named  and  typed. 
A  type  in  this  case  refers  to  an  IR  data  type,  not  the  Java  notion  of  type.  IR  types  are  represented 
by  objects  implementing  a  special  interface,  which  includes  methods  for  determining  if  an  object 
should  be  considered  an  instance  of  the  type  and  for  persisting  members  of  the  type.  The  framework 
provides  a  set  of  primitive  types  including  the  standard  scalar  types,  e.g.,  integer,  string,  etc.,  as  well 
as  several  complex  types  such  as  sequences  and  records.  Unfortunately,  using  this  kind  of  meta¬ 
level  type  system  means  that  programming  for  the  IR  involves  an  abundance  of  type  casts  and,  in 
general,  is  unable  to  take  advantage  of  the  type  safety  provided  by  the  Java  programming  language. 
(The  absence  of  generic  type  types  in  Java  contributes  to  this  problem.)  Attributes  arc  represented 
by  objects  that  are  maps  from  unique  identifiers  to  values.  Any  unique  identifier  may  be  given  a 
value  for  any  attribute.  Attributes  and  identifiers  can  be  created  dynamically. 

Complex  structures  are  built  in  the  IR  by  considering  a  given  set  of  identifiers  and  a  given  set 
of  attributes  to  define  the  scope  of  the  data  structure.  For  example,  trees  can  be  represented  by 
mapping  each  node  in  the  tree  to  a  unique  identifier,  by  defining  “parent”  and  “child”  attributes, 
and  by  managing  the  values  of  those  attributes  as  appropriate  to  maintain  the  structure  of  the  tree. 
Maintaining  representation  invariants  over  such  a  diverse  collection  of  objects  is  difficult.  The  IR, 
therefore,  contains  classes  that  provide  familial-  high-level  APIs,  implementations  of  which  manage 
and  abstract  the  underlying  attributes.  For  example,  the  Tree  class  provides  expected  tree  methods, 
such  as  getParent,  getChildren,  setChild,  and  depthFirstSearch;  these  methods  manage 
the  “parent”  and  “child”  attributes  “under  the  hood.”  Specifically,  the  IR  provides  a  sophisticated 
library  of  graph  classes  built  on  top  of  the  identifier-attribute  abstraction. 

Data  in  the  IR  actually  has  a  third  component:  version.  Most  simply,  a  complete  identifier- 
attribute-version  triple  represents  a  particular  value  at  particular  point  in  time.  Any  change  to 
any  value  produces  a  new  version.  The  IR  maintains  a  pointer  to  the  current  version,  which  may 
be  queried  and  reset  to  a  previous  version.  Our  implementation  is  transparently  optimized  by  not 
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remembering  any  versions  that  arc  never  asked  for.  An  additional  feature  of  IR  versioning  is  that  the 
version  space  is  tree-structured  rather  than  “time-ordered”  linear.  A  tree-structured  version  space 
allows  for  experimentation,  by  providing  the  ability  to  return  to  a  previous  version  and  making  new 
changes  to  the  values,  which  starts  a  new  branch  in  the  version  tree.  The  IR  provides  a  shadow 
model  of  the  version  space  implemented  as  an  IR  tree  data  structure. 

Finally  the  IR  supports  persistence,  that  is,  the  storage  and  restoration  of  subsets  of  in-memory 
IR  structures  to  and  from  the  file  system.  The  intention  is  that  these  subsets  be  defined  along  the 
lines  of  components  and  other  higher-level  abstractions.  Persistence  preserves  identity,  in  particular 
if  a  particular  identifier  is  persisted  into  two  different  (but  overlapping)  subsets  of  data,  then  even  if 
the  two  subsets  arc  loaded  into  two  different  JVMs  the  identifier  is  preserved  in  both  JVMs.  Identity 
is  even  preserved  through  structures  such  as  Java  Ob  j  ectStreams.  The  result  is  the  implementation 
of  the  abstraction  that  all  identifiers  always  exist. 

7.2.2  Representing  Java  Programs 

Our  tool  represents  a  Java  program  using  an  augmented  abstract  syntax  tree  (AST).  These  trees 
arc  stored  in  the  IR.  They  arc  represented  as  IR  trees  containing  an  additional  “operator”  attribute. 
In  addition  to  describing  the  role  of  the  node  in  the  program,  e.g.,  “if  statement,”  “field  reference 
expression,”  or  “method  declaration,”  the  value  of  this  attribute  constrains  the  number  of  children 
the  node  may  have  and  dictates  what  their  operators  may  be.  It  may  appeal-  to  be  redundant  to  build 
our  own  AST  when  Eclipse  already  maintains  one.  We  are  motivated  to  use  our  own  AST  for  several 
reasons.  From  the  point  of  view  of  expediency,  many  of  our  analyses  were  written  prior  to  our  use 
of  Eclipse  and  are  based  on  our  AST  representation.  More  to  the  point,  several  of  our  analyses 
are  control-flow  based  and  therefore  require  control-flow  graphs  (CFGs).  Eclipse  does  not  provide 
CFGs;  we  already  have  a  framework  for  generating  CFGs  from  our  own  ASTs.  As  a  project,  we 
made  the  engineering  decision  to  write  a  component  that  translates  Eclipse  ASTs  into  Fluid  ASTs 
so  that  we  would  not  have  to  modify  already  existing  and  working  analysis  code. 

Our  decision  to  continue  to  use  our  own  AST  representation  is  additionally  motivated  by  longer- 
term  project  goals  of  developing  new  techniques  for  (1)  visualizing  and  browsing  source  code  and 
models  of  design  intent  and  (2)  managing  program  evolution.  An  IR-based  AST  is  necessary  for 
both.  As  previously  mentioned,  versioning  is  intrinsic  to  the  IR — but  is  not  native  to  Eclipse — and 
thus  an  IR-based  AST  trivially  supports  evolution  management.  Our  project  has  also  developed  a 
model-view-controller  (MVC)  framework  on  top  of  the  IR  that  supports  elaborate  control  over  how 
models,  e.g.,  Java  programs  as  ASTs,  are  displayed.  Eclipse  provides  an  elegant  and  extensive  set 
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of  GUI  components  that  assist  us  in  the  ultimate  rendering  of  our  models,  but  does  not  provide  a 
suitable  MVC  framework.  Thus  supporting  within  Eclipse  our  project’s  visualization  research  still 
requires  the  translation  of  Eclipse  ASTs  into  Fluid  IR  representations. 

Our  control-flow  graphs  arc  built  from  IR-based  ASTs  following  a  “cookie  cutter”  design  pattern 
in  which  each  node  in  the  AST,  via  its  operator  value,  defines  a  control-flow  component,  that  has 
one  or  more  “holes”  in  it  filled  by  the  node’s  children.  More  specifically,  our  control-flow  graphs 
contain  explicit  edges  and  nodes  and  support  traversals  bidirectionally.  Analysis  results  arc  stored 
on  the  edges.  The  CFG  framework  is  not  Java  specific:  language  specific  control-flow  components 
arc  built  out  of  primitive  node  types  that  abstractly  determine  how  lattice  values  propagate  among 
subcomponents.  The  framework  provides  a  generic  work-list-based  control  flow  algorithm  that  is 
parameterized  by  a  language  and  analysis  specific  transfer  function  that  determines  the  specifics  of 
how  a  particular  operator  affects  the  incoming  lattice  value. 


7.3  Annotating  Missing  Code 

For  our  tool  to  be  practical  it  is  important  that  it  be  possible  to  annotate  “missing”  source  code 
with  models  of  design  intent.  Source  code  may  be  missing,  for  example,  because  a  library  is  only 
distributed  in  binary  form,  or  because  a  class  may  not  be  implemented  yet  even  though  its  interface 
has  been  designed.  Even  when  the  source  code  for  a  library  is  available,  it  is  convenient  to  be  able  to 
separate  annotations  added  by  the  user  of  the  library  from  the  source  code  of  the  library  itself,  such 
as  in  the  case  of  the  Java  standard  libraries.  Our  tool  is  capable,  therefore,  of  reading  annotations 
from  external  XMF-formatted  “promise”  files.  In  general,  the  convention  is  that  the  tool  looks  for 
annotations  for  the  class  package. class  in  the  file  package. class .  promises  .xml. 

Figure  7.3  shows  the  relevant  portions  of  the  j ava .  lang . Ob j ect  .promises  .xml  file  that 
describe  the  locking  preconditions  for  the  wait  and  notify  methods.  A  private  region  WaitQueue 
is  declared  on  line  7.  The  lock  MUTEX  is  declared  to  protect  that  region  and  to  be  represented  by 
this  on  line  9.  Finally,  the  wait  and  notify  methods  arc  given  the  annotation  @requiresLock 
MUTEX  on  lines  17,  22,  27,  32,  and  37.  We  also  see  that  the  constructor  is  annotated  to  have  no 
effects,  line  12,  and  to  not  create  aliases  to  the  newly  created  object,  line  13. 

ESC/Java  also  allows  the  external  annotation  of  source  code  using  specification  files  [FNSOO, 
§5.1.2].  Such  files  are  basically  annotated  Java  source  files  except  that  (1)  only  one  class  may 
be  described  in  the  file,  and  (2)  method  bodies  may  be  elided,  and  arc  ignored  even  if  they  arc 
present.  The  rccjava  tool  for  analyzing  RaceFreeJava  does  not  support  the  external  annotation 
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1  <?xml  version= " 1 . 0 "  encoding= "UTF- 8 " ? > 

2 

3  <!DOCTYPE  package  SYSTEM  "promises . dtd" > 

4 

5  <package  name=" java. lang"> 

6  cclass  name= "Obj ect " > 

7  <promise  keyword= " region"  contents= "private  WaitQueue"/> 

8  <promise  keyword= " lock" 

9  contents= "MUTEX  is  this  protects  WaitQueue"/> 

10 

n  <constructor> 

12  <promise  keyword= "writes "  contents= "nothing" /> 

13  <promise  keyword= "borrowed"  contents= " this " / > 

14  </constructor> 

15 

16  <method  name=  "notify "  > 

n  <promise  keyword= " requiresLock"  contents= "MUTEX" /> 

is  <promise  keyword= " reads "  contents= "nothing" / > 

19  </method> 

20 

21  <method  name=  "not if  yAll "  > 

22  <promise  keyword= " requiresLock"  contents= "MUTEX" /> 

23  <promise  keyword= " reads "  contents= "nothing" / > 

24  </method> 

25 

26  <method  name="wait"> 

27  <promise  keyword= " requiresLock"  contents= "MUTEX" /> 

28  <promise  keyword= " reads "  contents= "nothing" / > 

29  </method> 

30 

31  <method  name="wait"  params= " long" > 

32  <promise  keyword= " requiresLock"  contents= "MUTEX" /> 

33  <promise  keyword= " reads "  contents= "nothing" / > 

34  </method> 

35 

36  <method  name="wait"  params= " long,  int"> 

37  <promise  keyword= " requiresLock"  contents= "MUTEX" /> 

38  <promise  keyword= " reads "  contents= "nothing" / > 

39  </method> 

40 

41  <!--  And  so  on... - > 

42  </class> 

43  < /package  > 

Figure  7.3:  A  portion  of  the  file  j  ava .  lang .  Obj  ect .  promises  .  xml  that  contains  annotations 
for  the  class  j  ava .  lang .  Obj  ect.  The  annotations  themselves  are  shown  in  boldface. 
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of  libraries,  and,  in  fact,  specifically  suppresses  any  warnings  associated  with  declarations  within 
the  j  ava .  *  packages.3 

7.4  Annotations  and  Analyses 

Our  prototype  tool  implementation  supports  a  subset  of  the  annotations  and  analyses  described  in 
the  previous  chapters.  Some  of  the  analyses  arc  integrated  into  our  prototype  tool,  while  others  exist 
only  as  stand-alone  demos.  Table  7.1  lists  all  the  annotations  introduced  herein  and  summarizes  the 
extent  to  which  they  arc  supported  by  our  prototype  tool.  An  annotation  that  is  recognized  by 
our  tool  and  incorporated  into  our  internal  data  structures  is  considered  “in  tool.”  Analysis  may  use 
annotations  in  two  ways,  reflecting  the  use  of  annotations  as  outpoints:  (1)  to  assure  that  source  code 
is  consistent  with  the  design  intent  described  by  the  annotation,  and  (2)  to  support  the  assurance  of 
another  kind  of  design  intent.  In  the  table,  the  first  use  is  considered  “assured”  and  the  second 
“consumed.”  We  mark  a  class  of  annotations  as  consumed  only  if  it  is  used  by  an  analysis  actually 
present  in  the  tool.  Figure  7.4  graphically  shows  which  annotations  and  analyses  depend  on  each 
other,  fully  considering  effects  and  uniqueness.  Region  annotations,  for  example,  arc  used  not 
only  by  both  lock  and  effects  analysis,  but  by  effect  and  lock  annotations  because  they  provide  a 
vocabulary  for  describing  state. 

There  arc  some  caveats  to  note.  (1)  Our  prototype  tool  recognizes  all  the  previously  described 
annotations  except  for  the  meta-level  method  aggregation  annotations  and  those  related  to  region 
parameters  and  external  concurrency  policy.  (2)  We  also  do  not  yet  link  the  internal  concurrency 
policy  to  the  code.  (3)  Robustness  is  lacking,  in  particular,  the  tool  does  not  currently  enforce  that 
the  annotations  be  well  formed,  so  it  is  possible,  for  example,  to  associate  a  region  with  multiple 
locks,  or  to  extend  non-existent  regions.  The  behavior  of  analyses  in  such  situations  is,  of  course, 
undefined  and  the  tool  may,  as  result,  throw  exceptions  during  analysis. 

Not  all  of  the  annotations  need  to  be  checked  for  consistency  against  the  source  code.  The  re¬ 
gion  hierarchy  annotations  define  a  model  of  state  that  influences  the  assurance  of  other  pieces  of 
design  intent.  Thus  the  @region,  @mapInto,  and  ©aggregate  annotations  have  the  not  appli¬ 
cable  marker  “n/a”  in  the  “assured”  column  of  Table  7.1.  The  @methodSet  annotation,  while  not 
recognized  by  our  tool,  also  does  not  require  any  intrinsic  assurance.  Continuing  the  list  of  caveats, 
(4)  we  have  not  yet  defined  the  model  defined  by  @policyLock  annotations — although  it  clearly 
must  derived  from  the  internal  concurrency  policy — and  thus  there  is  not  yet  any  annotation-source 


3Personal  communication.  Stephen  Freund,  January  2003. 
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Annotations 

Cutpoint  Roles 

Annotation 

In  Tool 

Assured 

Consumed 

Method  Aggregation 

@methodSet  mset  =  method i ,  . .  .,  methodn  [,  .  .  .] 

N 

n/a 

N 

@set  mset  annotation 

N 

n/a 

N 

@inSet  mset 

N 

n/a 

N 

Region  Hierarchy 

@region  visibility  [static]  region  [extends  parentRegion ] 

Y 

n/a 

Y 

@map!nto  parentRegion 

Y 

n/a 

Y 

Region  Parameters 

@<region  region1 ,  ,  regionn> 

N 

N 

N 

@<targetl,  ...,  targetn> 

N 

N 

N 

Effects 

@reads  targeti ,  ,  target n 

Y 

N* 

N 

@writes  target  x targetn 

Y 

N* 

N 

Unshared  References 

@unshared 

Y 

N* 

Y 

©borrowed 

Y 

N* 

Y 

©aggregate  Si  into  d\ ,  .  . . ,  sn  into  dn 

Y 

n/a 

Y 

Locking  Model 

@lock  lockName  is  representation  protects  region 

Y 

Y 

Y 

@requiresLock  lockNamei ,  lockNamen 

Y 

Y 

Y 

@returnsLock  lockName 

Y 

Y 

Y 

©synchronized 

Y 

Y 

Y 

Policy 

@saf  ewith  methodi ,  methodn 

N 

N 

N 

@policyLock  lockName  is  representation 

Y 

n/a 

Y 

@self Protected 

Y 

N 

Y 

Table  7.1:  Annotations  supported  by  our  prototype  tool.  An  “N*”  in  the  assured  column  means  that 
the  analysis  is  implemented  but  is  not  currently  integrated  with  our  prototype  tool. 
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Figure  7.4:  Flow  of  annotation  and  analysis  information. 


code  consistency  to  assure  for  them  either.  Finally,  (5)  assurance  analyses  for  effects  and  unshared 
references  have  been  implemented,  but  they  are  not  yet  incorporated  into  our  prototype  assurance 
tool  because  they  do  not  directly  relate  to  concurrency  issues. 

7.4.1  Implementation  Notes 

Our  analyses  arc  primarily  predicated  on  the  region  hierarchy  and  state  aggregations  defined  by  the 
@region,  @mapInto,  and  ©aggregate  annotations.  Our  internal  representations  allow  queries 
based  on  the  tree  defined  by  the  annotations,  e.g.,  queries  of  region  inclusion.  As  previously  men¬ 
tioned,  region  parameterization  is  not  supported  in  our  prototype  tool.  Above  the  region  abstraction, 
we  implement  representations  for  targets,  which  arc  used  extensively  by  the  effects  and  locking  anal¬ 
yses.  Effects  analysis  is  implemented,  although  not  integrated  with  our  prototype  assurance  tool. 
The  implementation  is  based  on  the  presentation  of  effects  in  [GB99],  including  uniqueness  aggre¬ 
gation.  Effects  analysis  is  implemented  as  a  depth-first  walk  along  the  syntax  tree.  Comparison, 
elaboration,  and  other  operations  arc  defined  as  operations  on  effect,  target,  and  region  objects.  The 
results  of  comparison  operations,  e.g.,  effects  conflict,  arc  designed  to  be  helpful  for  providing  feed¬ 
back  to  the  programmer,  and  thus  return  bit  sets  encoding  rationale  for  the  result,  such  as  “the  first 
effect  is  a  write  whose  target  overlaps  with  the  target  of  the  second  effect  because  they  arc  instance 
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Positive  Assurances:  Method  returns  the  correct  lock  (at  method  declaration) 

Method’s  lock  preconditions  satisfied  (at  call  site) 

Field  is  accessed  with  the  correct  lock  held  (at  field  reference) 
Thread-local  constructor  keeps  receiver  from  escaping  (at  constructor) 


Assurance  Failures:  Method  does  not  return  the  correct  lock  (at  method  declaration) 
Method’s  lock  preconditions  not  satisfied  (at  call  site) 

Field  is  not  accessed  with  the  correct  lock  held  (at  field  reference) 
Thread-local  constructor  may  allow  receiver  to  escape  (at  constructor) 

Warnings:  Synchronized  method  does  not  access  any  shared  state 
Synchronized  block  does  not  access  any  shared  state 
Lock  expression  is  not  a  final  expression 
Cannot  identify  lock 

Field  references  a  possible  shared  unprotected  object 


Table  7.2:  The  specific  positive  assurances,  assurance  failures,  and  warnings  that  our  prototype  tool 
generates _ 

targets  whose  object  expressions  may  be  aliased  and  whose  regions  overlap.”  Because  our  tool  does 
not  currently  make  use  of  effect  conflict  results,  we  have  not  yet  incorporated  an  alias  analysis.  Our 
implementation  of  May  Equal  is  thus  the  most  conservative  possible:  it  always  returns  true. 

Our  implementation  of  effects  uses  what  we  call  “binding  context  analysis,”  formally  defined  in 
Section  3.4.  This  analysis  is  implemented  using  our  data-flow  analysis  framework  and  does  not  rely 
on  any  annotations. 

Uniqueness  analysis  as  described  in  [BoyOla]  is  implemented,  although  not  integrated  into  our 
tool.  It  assures  that  source  code  is  consistent  with  @unshared  and  ©borrowed  annotations.  It  is 
implemented  using  our  data-flow  analysis  framework.  There  is  a  dependence  between  the  unique¬ 
ness  and  effects  analyses.  The  cycle  of  assurance  is  broken  by  using  separately  assured  annotations 
as  outpoints  in  the  assurance  process.  That  is,  effects  uses  uniqueness  annotations  trusting  that  they 
are  correct,  and  uniqueness  uses  method  effect  annotations  trusting  that  they  are  correct. 

The  prototype  tool  implements  a  set  of  lock  analyses  based  on  the  annotations  and  analyses  of 
Chapter  5.  We  present  the  analysis  as  a  type  system  in  Section  5.11,  although  our  implementation 
is  as  a  suite  of  separate  analyses,  so  that,  for  example,  it  is  straightforward  to 

•  Determine  the  locks  held  when  a  given  expression  is  evaluated. 

•  Determine  the  lock  required  to  access  a  field.  This  exploits  uniqueness  aggregation  in  a 
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limited  way  to  account  for  the  aggregation  of  arrays. 

•  Determine  the  locks  required  to  invoke  a  method. 

•  Determine  if  a  method  returns  the  correct  lock. 

•  Determine  what  locks  an  expression  may  represent. 

These  building  blocks  make  it  easy  to  check  whether  any  particular  field  access  or  method  call  is 
consistent  with  the  locking  model.  In  addition  to  the  assurance  analyses,  we  also  implemented  the 
heuristics  of  Section  5.7.  Table  7.2  lists  the  specific  lock-related  positive  assurances,  assurance 
failures,  and  warnings  that  our  prototype  tool  generates. 

Lock  analysis  is  a  consumer  not  only  of  lock  annotations  but  also  of  region  annotations,  unique¬ 
ness  annotations,  and  policy  annotations.  The  analyses  arc  implemented  as  traversals  over  the  ab¬ 
stract  syntax  tree  and  manipulate  lock  objects  that  encapsulate  lock  identity  operations.  As  described 
in  Section  5.6,  our  implementation  uses  “final  expressions”  to  simplify  the  identification  of  locks. 
A  ©synchronized  constructor  is  assured  by  verifying  that  it  is  also  annotated  with  the  design  in¬ 
tent  that  it  does  not  produce  permanent  aliases  to  the  newly  created  object:  ©borrowed  this.  As 
previously  mentioned,  however,  our  tool  does  not  currently  assure  ©borrowed  annotations. 

We  have  not  implemented  any  policy-related  analyses.  Our  tool  recognizes  the  @policyLock 
annotation  which  is  used  to  assist  in  lock  identification.  The  @self  Protected  annotation  is  also 
recognized,  and  used  by  lock  analysis  to  determine  that  a  referenced  object  is  not  unprotected. 
Our  prototype  does  not  assure,  however,  that  the  annotated  class  is  consistent  with  the  concurrency 
policy  embodied  in  this  annotation. 


7.5  Assuring  BoundedFlFO 

We  now  use  the  familial-  BoundedFlFO  example  to  demonstrate  the  use  of  our  tool  to  provide  pos¬ 
itive  assurance  of  thread- safety.  This  example  demonstrates  the  incrementality  of  our  approach,  in 
which  a  few  annotations  are  added  at  each  step,  and  analyses  provide  increments  of  positive  assur¬ 
ance  as  more  annotations  are  introduced.  In  addition  to  exemplifying  the  programmer’s  interaction 
with  the  code  and  our  analysis  tool,  this  section  also  brings  together  all  the  observations  we  have 
made  about  BoundedFlFO  in  previous  chapters.  In  particular,  assurance  issues  relating  to  lock 
responsibility,  lock  acquisition,  lock  assignment,  and  state  aggregation  are  addressed. 

This  example  highlights  a  key  difference  between  our  assurance-based  approach  and  the  bug¬ 
finding  approaches  of  other  similar  projects.  BoundedFlFO  has  the  unusual  characteristic  of  actu- 
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[4^  Code  Quality  Advice  (7  issues) 

B  3  lock  expressions  not  identifiable  as  programmer-declared  locks;  what  lock  is  being  acquired? 

E)  ta?  BoundedFIFO  Example  (3  issues) 

S  ®  (default)  (3  issues) 

S  0  BlockingFIFO. java  (3  issues) 

^  line  9:  Lock  expression  'this.fifo'  is  not  identifiable  as  a  programmer-declared  lock 
^  line  23:  Lock  expression  'this.fifo'  is  not  identifiable  as  a  programmer-declared  lock 
^  line  39:  Lock  expression  'this.fifo'  is  not  identifiable  as  a  programmer-declared  lock 
S  4  lock  precondition(s)  satisfied 

El  S?  BoundedFIFO  Example  (4  issues) 

El-  3i  (default)  (4  issues) 

S  -  [J]  BlockingFIFO.  java  (4  issues) 

$  line  12:  Lock ' Cthis.f if o>. MUTEX'  held  when  invoking  this . f if o . wait() 

$  line  18:  Lock '< this. f if o>. MUTEX'  held  when  invoking  this . f if o . notif y () 

$  line  27:  Lock '  Cthis.f  if  o>.  MUTEX'  held  when  invoking  this.fifo.  wait() 

$  line  33:  Lock '  cthis.f  if  o>.  MUTEX'  held  when  invoking  this,  f  if  o.  notif  y() 


Code  Quality  Advice 


Search 


Figure  7.5:  Results  of  applying  our  prototype  tool  to  the  unannotated  BoundedFIFO  source  code. 


ally  being  correctly  written  with  respect  to  concurrency  issues.  Use  of  our  approach  provides  the 
evidence  that  the  program  is  correct.  Each  step  of  adding  a  new  element  of  design  intent  yields 
additional  assurances,  or  narrows  the  areas  of  suspicion  to  smaller  segments  of  code. 

Our  example  involves  three  classes  (1)  BoundedFIFO  as  taken  from  version  1.0.4  of  Log4j, 
(2)  Our  wrapper  class  BlockingFIFO  as  a  client  of  BoundedFIFO,  and  (3)  an  empty  stub  class 
LoggingEvent  as  a  place  holder  for  the  Log4j  class  LoggingEvent.  Initially  all  the  classes  are 
unannotated;  BoundedFIFO  is  as  in  Figure  1.2  and  BlockingFIFO  is  as  in  Figure  6.5.  We  will 
only  be  adding  annotations  to  the  class  BoundedFIFO. 

Running  our  analyses  on  the  unannotated  source  code  actually  provides  assurance  because 
BlockingFIFO  uses  wait  and  notify,  which  are  annotated  with  lock  preconditions.  Our  tool 
reports  “4  lock  precondition(s)  satisfied”  as  a  result  of  correctly  synchronizing  on  f  ifo  before  in¬ 
voking  f if o. wait,  etc.,  in  BlockingFIFO.  The  results  also  include  three  warnings  about  “lock 
expressions  not  identifiable  as  programmer-declared  locks;  what  lock  is  being  acquired?”  The  out¬ 
put  of  our  analyses  is  shown  in  Figure  7.5.  These  are  in  reference  to  the  three  synchronized 
blocks  in  get,  put,  and  length  respectively.  No  programmer-declared  lock  (the  lock  MUTEX  de¬ 
clared  by  the  Fluid  system  does  not  count)  is  associated  with  the  bounded  FIFO  object  (indeed,  there 
are  no  annotations  in  the  program  yet),  so  analysis  cannot  determine  what  lock  is  being  acquired  by 
these  blocks.  The  warning  is  intended  to  prod  the  programmer  into  introducing  design  intent  into 
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the  program. 

We  annotate  BoundedFlFO  with  our  initial  locking  design  intent:  (1)  the  state  is  protected 
by  locking  on  the  object  itself,  and  (2)  the  clients  arc  expected  to  acquire  the  locks.  The  anno¬ 
tation  @lock  BufLock  is  this  protects  Instance  is  added  to  the  class.  Each  method  is 
annotated  with  @requiresLock  BufLock.  For  the  sake  of  example,  we  “forget”  to  annotate  the 
method  get.  We  rerun  the  analysis.  The  results,  shown  in  Figure  7.6,  include  positive  assurances, 
assurance  failures,  and  warnings: 

•  There  arc  now  “10  lock  precondition(s)  satisfied.”  Analysis  recognizes  the  use  of  f  if  o  in  the 
synchronized  blocks  of  class  BlockingFIFO  as  a  possible  use  of  the  locks  BufLock  and 
MUTEX.  Combined  with  the  new  preconditions  on  the  BoundedFlFO  methods,  this  enables 
the  six  additional  method  callsites  to  be  assured.  The  assurance  message  in  the  results  window 
identifies  the  lock  expression  that  satisfies  the  precondition. 

•  Within  class  BoundedFlFO,  the  locking  preconditions  enable  the  assurance  that  at  15  sites, 
fields  of  the  class  arc  accessed  consistently  with  the  locking  model. 

•  Unfortunately,  analysis  also  reveals  nine  sites  where  fields  of  BoundedFlFO  arc  not  accessed 
according  to  the  model.  Here  the  error  message  indicates  the  lock  that  is  expected  to  be  held. 

•  There  is  a  warning  that  there  arc  2  sites  where  a  possibly  unprotected  object  is  accessed. 

Inspection  of  the  unprotected  field  accesses,  by  double-clicking  on  the  errors  in  the  results  win¬ 
dow,  reveals  that  many  of  the  unprotected  accesses  arc  in  the  method  get  (see  Figure  7.6).  This  is 
because  we  “forgot”  to  annotate  the  method  with  a  locking  precondition.  In  general,  the  error  could 
be  that  the  implementation  of  the  method  is  intended  to  acquire  the  lock.  Were  this  the  case  we  could 
satisfy  the  locking  model  by  declaring  the  method  to  be  synchronized.  It  is  our  intent,  however, 
that  the  caller  of  the  method  acquire  the  lock,  so  we  annotate  the  method  with  @requiresLock 
BufLock.  We  rerun  the  analyses;  the  results  arc  shown  in  Figure  7.7.  Introduction  of  this  one  anno¬ 
tation  increases  the  number  of  assured  method  calls  by  one,  because  there  is  now  one  more  method 
with  a  precondition  to  be  satisfied.  The  number  of  assured  field  accesses  increases  to  22. 

We  now  inspect  the  remaining  two  unsafe  field  accesses.  The  unsafe  accesses  arc  in  the  con¬ 
structor  of  the  class.  As  discussed  in  Section  5.5,  it  is  usually  safe  to  assume  that  the  object  is 
only  being  accessed  by  a  single  thread  while  it  is  being  constructed,  and  thus  synchronization  is 
unnecessary.  We  thus  annotate  this  design  intent  by  adding  the  ©synchronized  annotation  to  the 
constructor.  Rerunning  the  analysis  provides  us  with  additional  assurances,  but  also  with  a  new 
error;  see  Figure  7.8. 
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Figure  7.6:  Analysis  output  after  an  initial  attempt  to  define  the  locking  model. 
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Figure  7.7:  Analysis  output  showing  “unsafe”  field  accesses  in  the  constructor. 
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B 1  '©synchronized'  constructor(s)  with  escaping  receivers. 

B  £?  BoundedFIFO  Example  (1  issue) 

B  93  (default)  (1  issue) 

B-0  BoundedFIFO. java  (1  issue) 

^  line  31:  '©synchronized'  constructor  BoundedFIFO  has  escaping  receiver 
B  ^  1 1  lock  precondition(s)  satisfied 
B  #  24  protected  field  access(es) 

2  protected  reference(s)  to  a  possible  shared  unprotected  object;  possible  race  condition  detected 


Code  Quality  Advice 


Search 


Figure  7.8:  Analysis  output  showing  the  failure  to  assure  the  ©synchronized  annotation. 


4  & 


1  '©synchronized'  constructor(s)  with  thread-local  receivers.  I 
B  $  1 1  lock  precondition(s)  satisfied 
B-$?  24  protected  field  access(es) 

B  ^  2  protected  reference(s)  to  a  possible  shared  unprotected  object;  possible  race  condition  detected 
B  la?  BoundedFIFO  Example  (2  issues) 

B  ffl  (default)  (2  issues) 

B"@  BoundedFIFO. java  (2  issues) 

^  line  55:  Field  reference  'this.buf  [  this. first  ]'  may  be  to  a  shared  unprotected  object, 
line  73:  Field  reference  'this.buf  [  this. next  ]'  may  be  to  a  shared  unprotected  object. 


Code  Quality  Advice  Search 


Figure  7.9:  Analysis  output  showing  possible  unprotected  access  to  the  array  this  .buf. 


•  Documentation  of  the  assumption  allows  lock  analysis  to  assure  that  the  field  accesses  in  the 
constructor  are  consistent  with  the  locking  model. 

•  Unfortunately,  analysis  is  not  able  to  verify  that  the  constructor  is  single-threaded,  so  the 
assurance  failure  “’©synchronized’  constructor  BoundedFIFO  has  escaping  receiver”  is  re¬ 
ported. 

As  discussed  in  Section  5.5,  our  tool  implementation  uses  uniqueness  analysis  to  assure  the 
©synchronized  annotation.  We  introduce  the  additional  annotation  ©borrowed  this  on  the 
constructor.  Analysis  is  now  able  to  assure  that  the  constructor  is  indeed  thread  local;  see  Figure  7.9. 
(Our  tool  does  not  currently  assure  the  ©borrowed  annotations.  Here  we  assert  that  it  is  obvious 
that  the  constructor  does  not  create  any  aliases  to  the  newly  created  object.) 
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Figure  7.10:  Analysis  output  showing  full  positive  assurance  of  BoundedFlFO  with  respect  it  to  its 
annotated  locking  model. 
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We  now  turn  our  attention  to  the  remaining  warning:  “2  protected  reference(s)  to  a  possibly 
shared  unprotected  object.”  There  is  one  warning  for  each  dereference  of  the  array  referenced 
by  the  field  buf;  see,  again.  Figure  7.9.  The  relevant  issues  of  design  intent  and  assurance  arc 
discussed  in  other  places,  e.g.,  Sections  4.6  and  5.7.1.  To  summarize,  the  tool  is  bringing  to  our 
attention  the  fact  that  the  object  referenced  by  this  .buf  is  (1)  not  known  to  be  thread-safe  (that 
is,  it  does  not  have  design  intent  describing  how  to  preserve  its  invariants),  and  (2)  possibly  shared 
(that  is  referenced  by  multiple  threads  because  the  reference  may  be  generally  aliased).  Thus,  we 
may  be  accessing  a  shared  object  in  an  unsafe  manner.  As  described  previously,  the  solution  in 
this  case  is  to  document  the  intent  that  the  object  is  @unshared  and  to  aggregate  its  state  into  the 
state  of  the  BoundedFIFO  object.  We  add  the  annotations  @unshared  and  aggregate  []  into 
Instance  to  the  declaration  of  the  field  buf.  One  last  analysis  of  the  program  now  provides  only 
positive  assurances,  see  Figure  7.10: 

•  The  constructor  is  assured  to  be  thread-local. 

•  All  uses  of  methods  of  BoundedFIFO  by  class  BlockingFIFO  are  consistent  with  the  pre¬ 
conditions  of  those  methods. 

•  All  uses  of  fields  of  BoundedFIFO  arc  consistent  with  the  locking  model  of  that  state,  includ¬ 
ing  indexing  into  the  array  referenced  by  buf. 

Using  our  tool,  we  have  now  (1)  documented  concurrency-related  design  intent  for  Bounded¬ 
FIFO,  (2)  associated  that  design  intent  with  the  code,  and  (3)  assured  that  the  code  is  consistent  with 
that  intent. 


7.6  Assuring  Logger 

As  a  second,  more  complex,  example  of  using  the  tool  to  assure  production  Java  code,  we  present 

the  class  Logger  from  the  Java  2  SDK,  Standard  Edition  Version  1.4. 1 _ 01  j ava .  util .  logging 

package.  Like  Log4j,  this  package  implements  a  logging/debugging  API  [HamOl].  There  is  one 
Logger  instance  for  each  programmer-defined  component  of  interest.  A  Logger  object  thus  may 
be  shared  by  multiple  threads,  and  in  fact,  the  Javadoc  for  the  class  claims  that  “All  methods  on 
Logger  arc  multi-thread  safe.”  In  this  example,  we  must  reverse  engineer  the  original  design  intent. 
In  spite  of  this  “worst  case”  scenario  of  usage,  use  of  our  analysis  tool  reveals  that  the  class  contains 
several  concurrency-related  errors  which  we  must  fix  before  thread-safety  can  be  assured. 

We  assure  Logger  in  a  project  that  contains  the  minimum  subset  of  j  ava .  util .  logging  nec¬ 
essary  to  successfully  compile  the  class.  The  project  contains  the  source  files  for  ErrorManager, 
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Filter,  Formatter,  Handler,  Level,  LogManager,  LogRecord,  Logger,  and  LoggingPer- 
mission.  Our  analyses  will  report  items  of  interest  in  classes  other  than  Logger,  but  in  this 
example  we  arc  only  interested  in  assuring  the  single  class  so  we  do  not  focus  on  the  additional 
errors  and  warnings.  The  class  and  its  related  files  arc  too  large  to  be  shown  here;  we  highlight  the 
relevant  segments  of  code  as  necessary. 

This  example  also  demonstrates  our  need  to  develop  more  sophisticated  techniques  for  display¬ 
ing  the  output  of  our  analyses.  Such  concerns  arc  beyond  the  scope  of  this  dissertation,  although  we 
mention  them  here  as  a  warning  to  the  reader  of  the  lack  of  useful  visual  structuring  within  the  tool 
output  shown  in  the  figures  accompanying  this  example. 

7.6.1  A  Race  Condition  on  Field  filter 

As  in  the  previous  example,  we  begin  by  running  our  tool  on  unannotated  code.  Analysis  reports 
a  total  of  47  issues,  21  of  which  arc  in  the  Logger  class.  Of  these,  15  arc  related  to  concurrency4 
See  Figure  7.11.  The  first  item  of  interest  is  the  warning  “Line  407:  Lock  expression  'this'  is  not 
identifiable  as  a  programmer-declared  lock.”  We  begin  our  model-building  process  by  identifying 
the  lock  represented  by  this.  Inspection  of  the  contents  of  the  synchronized  block  reveals  that 
the  field  filter  is  the  only  state  of  the  object  accessed  within  that  critical  section.  Stalling  small — 
we  can  always  modify  our  intent  later — we  annotate  the  class  with  the  design  intent  that  this  is 
used  to  protect  the  field  filter: 

@lock  L  is  this  protects  filter 

After  reanalysis,  there  are  19  concurrency-related  issues  in  Logger;  see  Figure  7.12.  Instead  of 
the  warning  that  this  is  not  identifiable  as  a  lock,  analysis  now  returns  some  positive  assurances, 
some  assurance  failures,  and  some  additional  warnings  related  to  our  single  annotation: 

•  The  two  uses  of  filter  in  the  synchronized  block,  both  now  on  line  410,  are  positively 
assured  to  be  accessed  correctly. 

•  Two  uses  of  filter,  on  line  384  (highlighted  in  Figure  7.12)  and  line  393,  occur  in  contexts 
where  the  required  lock  is  not  held.  These  are  potential  race  conditions. 

•  There  are  seven  warnings  that  “Locks  [o.L,  o.MUTEX]  not  needed  by  body  of  synchro¬ 
nized  method.”  These  occur  because  these  seven  methods  acquire  the  lock  on  this  (by  virtue 
of  being  synchronized)  yet  they  do  not  use  the  region  filter  (nor  do  they  invoke  any  of 

4Our  prototype  tool  also  performs  several  other  “code  quality’-  analyses  unrelated  to  those  presented  in  this  disserta¬ 
tion.  Further  discussion  of  these  analyses  is  beyond  the  scope  of  this  work. 
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Figure  7.11:  Analysis  results  for  assuring  Logger  with  no  annotated  model. 
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Figure  7.12:  Analysis  results  after  protecting  field  filter. 
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the  condition-variable-related  methods).  Thus,  the  synchronization  is  suspicious,  and  sug¬ 
gests  that  we  may  need  to  associate  the  lock  this  with  additional  state. 

•  There  is  a  single  warning  that  the  object  referenced  by  filter  may  be  a  shared  unprotected 
object.  This  comes  from  the  method  invocation  shown  on  line  408  in  Figure  7.11. 

It  turns  out  that  there  is  a  real  race  condition  in  the  implementation  of  Logger,  which  we  have 
identified  as  a  consequence  of  this  study.5  Consider  method  setFilter  as  shown  in  Figure  7.12 
and  method  log  as  shown  in  Figure  7.11.  Method  setFilter  does  not  acquire  the  lock  before  as¬ 
signing  a  new  value  that  is  specifically  allowed  to  be  null  to  filter.  This  can  cause  a  null-pointer 
exception  in  log  because  clearly  the  intent  of  the  synchronizedblock  that  it  contains  is  to  prevent 
filter  from  becoming  null  once  it  has  been  verified  to  be  non-null.  To  be  compliant  with  the 
locking  model  and  thus  to  avoid  this  possibility,  methods  setFilter  and  get  Filter,  the  methods 
containing  the  unprotected  uses  of  filter  identified  above,  are  declared  to  be  synchronized. 

After  introducing  the  missing  synchronization,  analysis  again  reports  19  concurrency-related 
issues,  except  that  now  the  two  assurance  failures  regarding  setFilter  and  getFilter,  on  lines 
384  and  393  respectively,  are  replaced  by  positive  assurances;  see  Figure  7.13.  The  race  condition 
over  field  filter  is  now  fixed.  We  do  not  address  the  seven  warnings  related  to  filter  and  lock 
L  until  later  in  this  example. 

7.6.2  A  Global  Tree  Lock 

We  continue  by  documenting  the  design  intent  behind  additional  existing  critical  sections.  Still 
referring  to  Figure  7.13,  we  see  that  analysis  warns  that  on  lines  1112,  1348,  and  1378  “Lock 
expression  ‘java.util.logging.Logger.treeLock’  is  not  final.”  From  these  three  warnings  we  learn 
that 

•  The  object  referenced  by  the  static  field  treeLock  is  used  as  a  lock.  The  state  protected 
by  this  lock  is  not  yet  unidentified. 

•  The  field  treeLock  is  not  final,  making  it  unsafe  to  use  as  a  lock  because  the  object  that 
it  refers  to  can  change  over  time. 

An  obvious  first  step  for  us  to  take  to  address  these  warnings  is  to  declare  the  field  treeLock  to 
be  final.  While  doing  this,  we  find  that  the  declaration  of  the  field  is  informally  annotated  with 
design  intent  indicating  that  the  fields  parent,  kids,  and  levelObject  of  all  Logger  instances 

3We  reported  this  race  condition  to  the  java  bug  database:  http  :  /  /  developer .  j  ava .  sun .  com/developer/ 
bugParade/.  It  has  been  assigned  the  bug  id  4779253. 
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Figure  7.13:  Analysis  results  after  fixing  the  race  condition  over  filter. 
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160//  The  fields  relating  to  parent-child  relationships  and  levels 
161//  are  managed  under  a  separate  lock,  the  treeLock.  — 1 

162private  static  Object  ^^2^53  =  new  0bject(); 

163/7  We  keep  weak  references  from  parents  to  children,  but  strong 
164/7  references  from  children  to  parents. 

165 private  Logger  parent;  //  our  nearest  parent. 

166 private  ArrayList  kids;  //  UeakRef erences  to  loggers  that  have  i 

167 private  Level  levelObject; 

168 private  volatile  int  levelValue;  //  current  effective  level  vali 

169 

170  ** 

-±J  I 


Figure  7.14:  Design  intent  surrounding  field  treeLock. 


are  intended  to  be  protected  by  the  lock  on  the  object  referenced  by  Logger .  treeLock;  see  Fig¬ 
ure  7. 14. 

We  thus  take  the  following  actions  on  the  source  code: 

•  We  declare  the  static  field  treeLock  to  be  final. 

•  We  declare  a  new  static  region  abstracting  the  logger  hierarchy  information: 

@region  public  static  Loggerttierarchy 

•  We  populate  the  new  region  with  the  fields  parent,  kids,  and  levelObject.  We  also 
aggregate  the  state  of  the  list  referenced  by  kids  into  the  LoggerHierarchy  region.  We 
cannot  do  the  same  for  the  parent  field  because  Logger  objects  are  possibly  aliased,  if  for 
no  other  reason  than  by  virtue  of  having  multiple  children. 

•  We  associate  the  lock  represented  by  treeLock  with  the  new  region: 

@lock  TreeLock  is  treeLock  protects  LoggerHierarchy 

Reanalyzing  the  program  with  the  additional  design  intent  results  in  37  concurrency- related  issues 
(out  of  a  total  of  43  issues)  in  class  Logger.  The  three  earlier  warnings  regarding  treeLock  have 
been  replaced  with  21  new  analysis  results,  highlighted  in  Figure  7.15: 

•  Twelve  positive  assurances  that  fields  levelObject,  parent,  and  kids  are  accessed  ac¬ 
cording  to  the  annotated  locking  model. 

•  Eight  potential  violations  of  the  locking  model  where  TreeLock  is  needed  but  not  known  to 
be  held. 

•  An  additional  warning  on  line  1426  that  leveiobj  ect  “may  be  a  shared  unprotected  object.” 
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Figure  7.15:  Analysis  results  after  declaring  the  shared  region  LoggerHierarchy. 
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Figure  7.16:  Method  updateEf  f  ectiveLevel.  Note  the  assertion  on  line  1421. 
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Investigation  of  the  eight  locking  model  violations  reveals  that  getLevel,  the  getter  method  for 
field  levelob  j  ect,  does  not  acquire  TreeLock.  We  modify  the  method  to  conform  to  the  model: 

public  Level  getLevel ()  { 

synchronized (treeLock)  {  return  levelObject;  } 

}  - 

This  takes  care  of  the  model  violation  associated  with  line  1136.  The  other  seven  potential  lock¬ 
ing  model  violations  all  occur  within  the  implementation  of  method  updateEf  fectiveLevel,  a 
private  helper  method.  We  arc  lucky:  the  method  is  already  informally  annotated  with  design 
intent,  see  line  1421  in  Figure  7.16.  A  comment  contains  the  assertion  that  the  current  thread  should 
hold  the  lock  on  the  object  referenced  by  treeLock.  We  declare  this  design  intent  formally  by 
annotating  the  method  with 

@requiresLock  TreeLock 

Reanalysis  now  assures  that  the  callers  of  the  method  adhere  to  the  newly  extended  locking  model. 
The  complete  results  arc  omitted;  of  particular  interest  here  arc  (1)  the  three  positive  assurances — 
and  no  assurance  failures — that  updateEf  fectiveLevel  is  called  consistently  with  the  locking 
model;  and  (2)  the  20  positive  assurances  that  the  fields  in  region  LoggerHierarchy  are  accessed 
consistendy  with  the  locking  model. 

Regarding  the  protection  of  state  in  region  LoggerHierarchy,  it  remains  to  address  the  warn¬ 
ing  that  field  levelObject  may  be  a  shared  unprotected  object.  This  warning  originates  from  the 
method  call  “levelob  j  ect .  intValue  ( )  ”  on  line  1426  in  Figure  7. 16.  Here,  analysis  requires 
more  information  about  the  thread-safety  of  Level  objects.  A  brief  inspection  of  Level  (source 
code  omitted)  suggests  that  the  class  is  intended  to  be  a  type-safe  enumeration  of  immutable  objects 
[BloOla].  Thus,  Level  objects  arc  sharable  by  multiple  threads  because  they  arc  intended  to  be 
immutable.  We  annotate  class  Level  with  this  intent  by  adding  the  annotation 

@self Protected 

(Recall  that  this  annotation  declares  that  the  implementation  of  the  class  is  completely  responsible 
for  insuring  its  own  thread-safety.)  Analysis  now  reports  45  issues  in  Logger,  39  of  which  arc 
concurrency-related.  Again,  we  omit  the  complete  results,  but  of  specific  interest  is  that  the  warning 
about  the  possibly  shared  use  of  leveiobj  ect  is  no  longer  reported. 
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7.6.3  The  Locking  Model  Thus  Far 

We  have  now  (1)  documented  a  subset  of  the  locking  model  for  Logger  objects,  and  (2)  assured 
that  the  source  code  is  consistent  with  the  model.  We  used  an  iterative  process  of  introducing 
small  numbers  of  annotations,  fixing  code  to  be  consistent  with  the  expressed  design  intent,  and 
then  repeating  analysis  incrementally  to  and  assure  source  code-model  consistency.  Specifically 
we  have  declared  the  following  model,  shown  graphically  in  Figure  7.22(a). 

•  The  region  filter  is  protected  by  locking  the  Logger  object  itself.  This  lock  is  named  “l.” 

•  The  region  LoggerHierarchy,  the  parent  region  of  fields  parent,  kids,  and  level - 
Object  of  all  Logger  objects,  is  protected  by  locking  the  object  referenced  by  the  static 
field  Logger .  treeLock.  This  lock  is  named  “TreeLock.” 

•  The  state  of  the  list  referenced  by  the  kids  field  is  aggregated  into  the  region  Logger- 
Hierarchy,  and  thus  also  protected  by  TreeLock. 

•  The  caller  of  the  method  updateEf  f  ectiveLevel  must  acquire  TreeLock. 

7.6.4  A  Policy  Lock 

We  now  turn  our  attention  to  four  warnings,  originally  reported  on  lines  206,  234,  284,  and  313 
in  Figure  7.11,  that  we  have  ignored  thus  far:  “Class  reference  ‘.class’  is  not  associated  with  a 
region.”  These  warnings  identify  four  static  synchronized  methods:  methods  that  acquire 
the  lock  on  the  object  referenced  by  Logger .  class.  This  object  has  not  been  explicitly  declared 
to  represent  a  lock,  and  thus  the  analysis  is  unable  to  assure  anything  about  the  critical  sections 
defined  by  these  methods.  The  four  methods  arc  factory  methods  for  getting  references  to  Logger 
objects,  and  have  the  same  general  form;  Figure  7.17  shows,  for  example,  getLogger  (String) . 
These  arc  the  only  places  where  the  lock  represented  by  the  object  referenced  byLogger .  class 
is  acquired;  there  would  be  additional  warnings  were  it  used  elsewhere.  There  arc  no  fields  that 
should  obviously  be  associated  with  the  lock;  in  particular,  no  mutable  Logger  state  is  directly 
accessed  in  the  getLogger  method  in  Figure  7.17.  Given  this  information  and  the  similar  structure 
of  all  the  methods,  we  infer  the  design  intent  that  the  lock  is  used  to  prevent  a  race  condition  during 
the  creation  Logger  objects  that  could  cause  multiple  Logger  instances  with  the  same  name  to  be 
created,  a  violation  of  higher-level  abstractions  in  the  API  of  the  package. 

This  use  of  the  object  referenced  by  Logger,  class  is  consistent  with  our  notion  of  policy 
locks:  locks  that  arc  not  associated  with  state,  but  that  are  used  to  enforce  consistency  with  a  class’s 
internal  concurrency  policy.  To  document  that  this  is  the  intent  behind  this  use  of  Logger,  class, 


7.6.  ASSURING  logger 


161 


public  static  synchronized  Logger  getLogger (String  name)  { 
LogManager  manager  =  LogManager . getLogManager () ; 

Logger  result  =  manager . getLogger (name) ; 
if  (result  ==  null)  { 

result  =  new  Logger(name,  null); 
manager . addLogger (result) ; 
result  =  manager . getLogger (name) ; 

} 

return  result; 

} 


_ Figure  7  17-  The  factory  method  Logger-  getLogger  (Stri  ng) _ 

and  as  a  result  to  suppress  the  four  warnings,  we  add  to  class  Logger  the  annotation 
@policyLock  SerializeLoggerCreation  is  class 
Analysis  now  reports  35  concurrency-related  issues,  highlighted  in  Figure  7.18: 

•  Three  positive  assurances  that  the  lock  precondition  on  updateEf f ectiveLevel  is  re¬ 
spected. 

•  Twenty-four  positive  assurances  that  fields  arc  accessed  according  to  the  locking  model. 

•  Seven  warnings  that  lock  L  is  acquired  but  not  needed.  Specifically,  the  methods  add- 
Handler,  removeHandler,  getHandlers,  setUseParentHandlers,  getUseParent- 
Handlers,  f indResourceBundle,  and  setupResourcelnf o  are  synchronized  but  do 
not  use  the  field  filter,  the  sole  field  associated  with  the  lock  represented  by  this. 

•  One  warning  that  filter  may  be  a  shared  unprotected  object. 


7.6.5  Expanding  the  Locking  Model 

The  seven  warnings  about  synchronized  methods  suggest  that  our  reverse-engineered  locking 
model  needs  to  be  expanded  to  include  more  state.  Five  of  the  methods  involved  in  the  warnings, 
shown  in  Figure  7. 19,  are  related  to  managing  a  list  of  Handler  objects  associated  with  the  Logger. 
A  brief  inspection  of  the  methods,  and  some  surrounding  code,  suggests  additional  design  intent: 

•  Field  manager  is  immutable,  and  ought  to  be  declared  final. 

•  Field  handlers  is  protected  by  the  lock  represented  by  this,  as  is  the  state  of  the  Array- 
List  that  it  references. 

•  Field  useParentHandlers  is  protected  by  the  lock  represented  by  this. 

We  document  this  intent,  which  replaces  our  previous  locking  model,  by 


162 


CHAPTER  7.  TOOLS 


Figure  7.18:  Analysis  results  after  declaring  Logger .  class  to  represent  a  policy  lock. 
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1  public  synchronized  void  addHandler (Handler  handler) 

2  throws  SecurityException  { 

3  //  Check  for  null  handler 

4  handler . getClass () ; 

5  if  (! anonymous)  { 

6  manager . checkAccess () ; 

7  } 

8  if  (handlers  ==  null)  { 

9  handlers  =  new  ArrayListO; 

10  } 

n  handlers . add (handler)  ; 

12  } 

13 

14  public  synchronized  void  removeHandler (Handler  handler) 

15  throws  SecurityException  { 

16  if  (!  anonymous)  { 

n  manager . checkAccess () ; 

18  } 

19  if  (handler  ==  null)  { 

20  throw  new  NullPointerException  ( )  ; 

21  } 

22  if  (handlers  ==  null)  { 

23  return; 

24  } 

25  handlers  .  remove  (handler)  ; 

26  } 

27 

28  public  synchronized  Handler  []  getHandlers  ( )  { 

29  if  (handlers  ==  null)  { 

30  return  emptyHandlers  ; 

31  } 

32  Handler  result  []  =  new  Handler [handlers . size ()] ; 

33  result  =  (Handler!])  handlers . toArray (result) ; 

34  return  result; 

35  } 

36 

37  public  synchronized  void 

38  setUseParentHandlers (boolean  useParentHandlers)  { 

39  if  (!  anonymous)  { 

40  manager .  checkAccess  ()  ; 

41  } 

42  this . useParentHandlers  =  useParentHandlers; 

43  } 

44 

45  public  synchronized  boolean  getUseParentHandlers ( )  { 

46  return  useParentHandlers; 

47  } 


Figure  7.19:  The  five  “handler”-related  methods  from  class  Logger. 
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j  k  k 

*  A  Filter  can  be  used  to  provide  fine  grain  control  over 

*  what  is  logged,  beyond  the  control  provided  by  log  levels. 

*  <p> 

*  Each  Logger  and  each  Handler  can  have  a  filter  associated  with  it. 

*  The  Logger  or  Handler  will  call  the  isLoggable  method  to  check 

*  if  a  given  LogRecord  should  be  published.  If  isLoggable  returns 

*  false,  the  LogRecord  will  be  discarded. 

* 

*  (©version  1.3,  12/03/01 

*  (©since  1.4 
*/ 

public  interface  Filter  { 

/  *  * 

*  Check  if  a  given  log  record  should  be  published. 

*  @param  record  a  LogRecord 

*  (©return  true  if  the  log  record  should  be  published. 

*/ 

public  boolean  isLoggable (LogRecord  record) ; 

} 


Figure  7.20:  The  Filter  interface. 


•  Declaring  that  manager  is  final. 

•  Declaring  a  new  region,  via  annotation,  Loggerlnfo,  and  populating  it  with  the  fields 
filter,  handlers,  and  useParentHandlers. 

•  Annotating  that  handlers  is  unaliased,  and  that  the  state  of  the  list  should  be  aggregated 
into  the  state  of  the  Logger: 

j  k  k 

*  (©maplnto  Loggerlnfo 

*  @unshared 

*  ©aggregate  Instance  into  Loggerlnfo 

*/ 

private  ArrayList  handlers; 

•  Replacing  our  original  (©lock  annotation 

@lock  L  is  this  protects  filter 

with 

@lock  InfoLock  is  this  protects  Loggerlnfo 
A  graphical  representation  of  the  modified  model  is  shown  in  Figure  7.22(b). 

We  also  now  deal  with  the  long-ignored  warning  that  filter  refers  to  a  possibly  shared  unpro¬ 
tected  object.  The  field  is  of  type  Filter,  an  interface  shown  in  Figure  7.20.  Clearly  implemen¬ 
tations  of  the  class  must  be  thread-safe:  after  all,  the  filter  may  be  used  by  many  Logger  objects. 
We  thus  declare  the  design  intent  that  implementations  of  Filter  should  protect  themselves  by 
annotating  the  interface  with  @self  Protected. 
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1  //  Private  utility  method  to  map  a  resource  bundle  name  to  an 

2  //  actual  resource  bundle,  using  a  simple  one-entry  cache. 

3  //  Returns  null  for  a  null  name. 

4  //  May  also  return  null  if  we  can't  find  the  resource  bundle  and 

5  //  there  is  no  suitable  previous  cached  value. 

6  private  synchronized  ResourceBundle  findResourceBundle (String  name)  { 

7  //  Return  a  null  bundle  for  a  null  name. 

8  if  (name  ==  null)  {  return  null;  } 

9 

10  Locale  currentLocale  =  Locale . getDefault () ; 

11 

12  //  Normally  we  should  hit  on  our  simple  one  entry  cache. 

13  if  (catalog  !=  null 

14  &&  currentLocale  ==  catalogLocale 

15  &&  name  ==  catalogName)  { 

16  return  catalog; 

17  } 

18 

19  //  Use  the  thread's  context  ClassLoader.  If  there  isn't  one, 

20  //  use  the  SystemClassloader . 

21  ClassLoader  cl  =  Thread . currentThread (). getContextClassLoader () ; 

22  if  (cl  ==  null)  {  cl  =  ClassLoader . getSystemClassLoader () ;  } 

23  try  { 

24  catalog  =  ResourceBundle . getBundle (name ,  currentLocale,  cl); 

25  catalogName  =  name; 

26  catalogLocale  =  currentLocale; 

27  return  catalog; 

28  }  catch  (MissingResourceException  ex)  { 

29  //  Woops .  We  can't  find  the  ResourceBundle  in  the  default 

30  //  ClassLoader.  Drop  through. 

31  } 

32 

33  //  Fall  back  to  searching  up  the  call  stack  and  trying  each 

34  //  calling  ClassLoader. 

35  for  (int  ix  =  0;;  ix++)  { 

36  Class  clz  =  sun . ref lect . Ref lection . getCallerClass (ix) ; 

37  if  (clz  ==  null)  { 

38  break  ; 

39  } 

40  ClassLoader  cl2  =  clz . getClassLoader ( ) ; 

41  if  (cl2  ==  null)  {  cl2  =  ClassLoader . getSystemClassLoader () ;  } 

42  if  (cl  ==  cl2)  { 

43  //  We've  already  checked  this  classloader. 

44  continue; 

45  } 

46  Cl  =  Cl2  ; 

47  try  { 

48  catalog  =  ResourceBundle . getBundle (name ,  currentLocale,  cl); 

49  catalogName  =  name; 

50  catalogLocale  =  currentLocale; 

51  return  catalog; 

52  }  catch  (MissingResourceException  ex)  { 

53  //  Ok,  this  one  didn't  work  either. 

54  //  Drop  through,  and  try  the  next  one. 

55  } 

56  } 

57 

58  if  (name . equals (catalogName) )  { 

59  //  Return  the  previous  cached  value  for  that  name. 

60  //  This  may  be  null. 

61  return  catalog; 

62  } 

63  //  Sorry,  we're  out  of  luck. 

64  return  null; 

65  } 


Figure  7.21:  The  method  findResourceBundle.  Uses  of  fields  catalog,  catalogName,  and 
catalogLocale  are  in  boldface. 
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The  remaining  two  methods  that  acquire  Inf  oLock  but  that  do  not  access  any  state  in  its  asso¬ 
ciated  region  are  f  indResourceBundle  and  setupResourcelnfo.  Method  f indResource- 
Bundle,  whose  implementation  is  shown  in  Figure  7.21,  can  be  executed  in  multiple  threads  at 
once.  It  is  invoked,  for  example,  by  several  of  the  public  logging  methods.  It  is  clear  that  the  values 
of  catalog,  catalogName,  and  catalogLocale  should  be  kept  in  sync  with  each  other,  and 
thus  make  up  the  state  being  protected  during  execution  of  the  method.  We  add  this  design  intent  to 
the  class  by 

•  Declaring  a  new  region  Catalog  as  a  subregion  of  Loggerlnf o. 

•  Populating  the  new  region  with  the  fields  catalog,  catalogName,  and  catalogLocale. 
The  modified  model  is  shown  graphically  in  Figure  7.22(c). 

7.6.6  Unclear  Intent 

Method  setupResourcelnfo,  shown  in  Figure  7.23,  is  more  interesting  despite  being  a  very  sim¬ 
ple  method  that  only  (1)  calls  f  indResourceBundle  to  check  that  the  named  resource  exists,  and 
(2)  assigns  the  name  of  the  resource  to  the  field  resourceBundleName.  The  obvious  state  being 
protected  is  the  aforementioned  field.  The  associated  getter  method,  however,  is  not  declared  to  be 
synchronized,  and  this  should  be  recognized  as  an  error.  Were  we  to  add  resourceBundleName 
to  our  protected  region  Loggerlnf  o,  the  getter  would  be  identified  as  being  inconsistent  with  the 
model.  However,  the  only  other  direct  uses  of  the  field  arc  in  one  of  the  getLogger  factory  meth¬ 
ods,  which  is  also  the  only  place  outside  of  the  constructor  where  setupResourcelnfo  is  called. 
As  we  have  seen  already,  getLogger  is  already  synchronized,  and  thus  any  additional  locking 
to  protect  resourceBundleName  is  overkill.  But  we  cannot  have  both  this  and  Logger,  class 
protect  the  field. 

What  is  the  intent  of  the  designers  of  the  class  is  not  clear  at  this  point.  We  proceed  with  our 
assurance  process  based  on  the  following  additional  observation:  the  value  of  the  field  resource¬ 
BundleName  does  not  need  to  be  kept  in  sync  with  the  values  of  any  other  fields.  It  only  needs  syn¬ 
chronization  (1)  for  higher-level  policy  decisions,  but  this  already  correctly  occurs  in  getLogger, 
and  (2)  for  ensuring  that  changes  to  its  value  propagate  in  Java’s  memory  model.  But  this  later 
task  can  also  be  accomplished  by  declaring  the  field  to  be  volatile.  Finally,  there  do  not  ap¬ 
pear  to  be  any  consistency  constraints — /.<?.,  internal  concurrency  policy  concerns — that  require  the 
invocation  of  f  indResourceBundle  and  the  update  of  resourceBundleName  to  occur  within 
a  single  critical  section.  We  conclude  that  the  best  way  to  address  the  remaining  warning  regal'd- 
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(a) 


(c) 


Figure  7.22:  Evolution  of  the  state  and  locking  model  for  Logger.  These  diagrams  do  not  account 
for  policy  locks  or  state  aggregation,  (a)  The  model  after  protecting  filter  and  identifying  region 
LoggerHierarchy.  (b)  The  model  after  expanding  the  protected  state  to  include  the  newly  defined 
Loggerlnf  o  region.  The  field  manager  is  removed  from  the  model  because  it  has  been  declared 
to  be  final,  (c)  The  model  after  identifying  the  Catalog  region. 
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private  synchronized  void  setupResourcelnfo (String  name)  { 
if  (name  ==  null)  { 
return; 

} 

ResourceBundle  rb  =  f indResourceBundle (name) ; 
if  (rb  ==  null)  { 

//  We've  failed  to  find  an  expected  ResourceBundle. 
throw  new  MissingResourceException ( 

"Can't  find  "  +  name  +  "  bundle",  name,  ""); 

} 

resourceBundleName  =  name; 

} 


Figure  7.23:  The  method  setupResourcelnfo. 


ing  setupResourcelnfo  is  by  (1)  declaring  the  field  resourceBundleName  to  be  volatile, 
which  removes  it  from  the  scope  of  the  locking  model;  and  (2)  removing  the  synchronized  dec¬ 
laration  from  setupResourcelnfo. 

Analysis  now  gives  only  positive  assurance  results  regarding  concurrency  related  properties  of 
Logger;  see  Figure  7.24.  We  have  thus  used  our  tool  and  iterative  assurance  process  to 

•  Document  the  locking  model  used  by  class  Logger. 

•  Assure  consistency  between  this  model  and  the  source  code. 

•  Discover  a  race  condition  that  could  result  in  an  exception. 

•  Discover  several  “minor”  race  conditions  that  can  result  in  inconsistent  views  of  memory. 

•  Uncover  an  piece  of  policy  intent  that  probably  needs  further  consideration  by  the  designers 
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Figure  7.24:  Analysis  results  assuring  Logger  to  be  consistent  with  its  declared  locking  model. 


Chapter  8 


Towards  a  Generative  Approach  to 
Concurrency  Management 


The  assurance  techniques  described  in  the  previous  chapters  provide  the  foundations  for  using  pro¬ 
gram  transformation  techniques  to  manage  the  concurrent  attributes  of  a  program.  This  chapter  is  a 
speculative  excursion,  and  elaborates  some  of  the  ideas  of  this  generative  approach  to  concurrency 
management  using  examples  of  notional  transformation  scenarios  and  describes  preliminary  results 
on  the  required  transformations.  Semantics-based,  behavior-preserving,  source-level,  concurrency- 
related  program  transformations  are  a  fundamental  building  block  of  the  generative  approach.  Our 
usage  scenario  is  that,  in  a  programming  environment,  the  application  of  a  transformation  is  initiated 
by  the  programmer,  but  it  is  performed  by  a  software  tool  along  with  the  necessary  analyses,  relying 
on  program  annotations  expressing  programmer  design  intent.  A  transformation,  by  our  definition, 
is  meaning-preserving  with  respect  to  the  programmer-specified  concurrency-related  design  intent. 
This  means  that  a  transformation  does  not  result  in  inappropriate  accesses  to  shared  regions,  and  that 
concurrency  policy  is  respected.  In  general,  deadlock  avoidance  is  also  an  issue.  This  dissertation 
does  not  present  techniques  for  capturing  design  intent  regarding  deadlock  avoidance,  and  thus  we 
do  not  consider  deadlock  any  further  in  this  chapter. 

We  first  review  what  is  the  generative  approach,  and  give  a  sample  of  basic  transformations  that 
make  up  the  approach.  We  then  present  a  series  of  examples  that  demonstrate  the  use  of  transforma¬ 
tions  within  the  generative  approach.  Our  intent  is  to  expose  the  difficulty  in  determining  the  proper 
preconditions  for  soundness  of  a  transformation — what  we  describe  arc  not  always  transformations 
by  the  above  definition  because  they  may  fail  to  preserve  program  safety  relative  to  the  program¬ 
mer’s  intent.  Through  these  examples,  we  also  describe  some  of  the  techniques  a  tool  might  use  to 
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insure  safety,  and  identify  the  division  of  labor  between  the  programmer  and  tool.  The  examples 
suggest  the  operation  of  many  of  the  transformations.  We  follow  the  examples  with  a  brief  elabo¬ 
ration  of  the  operation  of  and  issues  raised  by  two  transformations,  split  lock  and  shrink  critical 
section.  Finally,  we  discuss  related  work  on  transformational  approaches  to  concurrent  program¬ 
ming. 


8.1  The  Generative  Approach 

The  goal  of  the  generative  approach  to  concurrency  management  is  to  establish  a  principled  ap¬ 
proach  to  the  introduction  and  management  of  concurrency,  allowing  the  trading  off  of  performance 
and  concurrency  to  be  explored  without  disturbing  functionality  and  while  keeping  program  com¬ 
plexity  manageable.  Concurrency-related  source-level  program  transformations  by  themselves  arc 
not  enough  to  maintain  the  safety  of  a  concurrent  program  as  it  evolves  in  a  practical  engineering  ap¬ 
proach.  The  transformations  themselves  must  be  applied  with  respect  to  a  programming  discipline 
that  further  insures  that  the  annotations  used  by  the  transformations  arc  correct  and  stay  correct,  and 
that  manages  the  introduction  and  evolution  of  concurrency  policy.  The  generative  approach  thus 
consists  of  applying  program  transformations  in  a  framework  of  assurance  and  annotation  manage¬ 
ment.  Adherence  to  the  generative  approach  insures  that  a  concurrent  program  is  always  free  of  race 
conditions  as  defined  by  a  programmer  specified  policy.  It  is  based  on  the  observation  that  it  is  easier 
to  stay  in  such  a  state  than  to  initially  arrive  at — be  proven  to  be  in — such  a  state  given  an  arbitrary 
concurrent  program.  So  that  the  concurrent  program  is  known  to  be  initially  safe,  the  generative 
approach  prescribes  a  specific  technique  for  increasing  the  extent  of  concurrency  in  programs:  they 
must  be  generated  from  initial  sequential  programs. 

Transformations  arc  performed  by  the  tool  on  the  behalf  of  the  programmer  and  their  safety 
is  verified  using  program  analyses  supported  by  programmer-specified  design  intent.  It  is  our  be¬ 
lief  that  tool  support  is  essential  to  making  our  approach  practicable.  Responsibility  for  design 
intent  and  safety  is  partitioned  between  the  programmer  and  the  tool:  the  tool  strictly  regulates 
the  introduction  and  management  of  concurrency-related  annotations  and  transformations,  while 
the  programmer  is  in  complete  control  of  the  original  partitioning  of  a  class  into  regions  and  other 
expressions  of  design  intent. 

We  simplify  the  following  discussion  by  only  considering  the  transformation  of  final  classes, 
that  is,  classes  that  cannot  have  subclasses. 
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8.1.1  Catalog  of  Transformations 

We  have  identified  a  number  of  transformations  that  arc  fundamental  to  the  generative  approach  to 
concurrency  management.  The  generative  approach  is  first  applied  to  a  non-concurrent  implemen¬ 
tation  of  a  class  using  the  synchronize  class  transformation.  The  class  is  reimplemented  as  a  simple 
monitor  and  given  a  default  concurrency  policy  with  which  it  is  already  compliant.  The  extent  of 
concurrency  supported  by  the  class  can  then  be  manipulated  by  a  variety  of  transformations.  Split 
lock  decreases  the  granularity  at  which  state  is  protected  by  moving  it  “down”  the  region  hierarchy. 
A  single  shared  region  is  replaced  with  many  shared  regions  based  on  its  subregions.  The  gran¬ 
ularity  of  protection  may  be  moved  “up”  the  region  hierarchy  using  merge  locks,  which  replaces 
multiple  shared  regions  with  a  single  ancestor  shared  region.  The  scope  of  a  critical  section  may  be 
altered  using  shrink  critical  section. 

Additional  opportunities  for  allowing  method  interleaving  may  be  introduced  using  split  crit¬ 
ical  section  to  convert  a  single  synchronized  block  into  a  sequence  of  synchronized  blocks. 
The  dual  merge  critical  sections  may  be  used  to  remove  interleaving  opportunities.  Altering  the 
programmer-specified  concurrency  policy  based  on  the  modified  interleaving  opportunities  is  a  sep¬ 
arate  step  in  the  generative  process.  The  implement  policy  transformation  is  used  to  reify  the  policy 
in  the  implementation. 

Locking  responsibility  may  be  modified  using  the  synchronize  method  and  synchronize  call- 
site  transformations,  which  move  the  responsibility  to  the  implementation  or  the  caller,  respectively. 
These  transformations  affect  a  wider  body  of  code  because  of  the  necessity  of  identifying  and  up¬ 
dating  method  callsites. 

Our  approach  to  annotation,  analysis,  and  transformation  is  based  on  regions  as  shared  re¬ 
sources.  Transformations  that  affect  the  region  hierarchy  and  the  aggregation  of  state  arc  also  basic 
building  blocks  of  the  generative  approach. 


8.2  Evolving  EventQueue 

We  now  use  the  generative  approach  to  increase  the  amount  of  concurrency  exploitable  by  clients 
of  the  class  EventQueue.  This  class  implements  a  simple  queue  that  buffers  events,  represented  as 
Objects.  Listeners  register  themselves  with  the  queue  using  implementations  of  the  EQListener 
interface,  which  receives  events  from  the  queue  using  the  dequeued  callback.  Figure  8. 1  shows 
the  class  after  it  has  been  made  initially  concurrent  using  the  synchronize  class  transformation. 
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This  transformation  modifies  the  original  sequential  version  of  the  class  by  (1)  declaring  a  new 
lock  that  protects  the  Instance  region,  see  line  3;  (2)  declaring  each  non-private  method  to 
be  synchronized;  and  (3)  declaring  a  lock  precondition  on  each  private  method,  such  as  on 
line  46. 

Instances  of  EventQueue  have  three  abstract  instance  regions:  (1)  Instance,  inherited  from 
Object;  (2)  Listeners,  a  subregion  of  Instance,  contains  the  state  of  the  List  referenced  by 
listeners;  and  (3)  Queue,  a  subregion  of  Instance,  contains  the  field  len  and  the  state  of  the 
List  referenced  by  queue.  To  increase  the  amount  of  concurrent  access  supported  by  the  class 
we  wish  to  (1)  modify  the  granularity  of  locking  based  on  the  region  hierarchy  so  that  the  queue’s 
listeners  and  the  queue’s  data  arc  separately  protected,  and  (2)  minimize  the  scope  of  the  resulting 
critical  sections. 

8.2.1  Splitting  the  Lock 

Splitting  a  lock  alters  a  program  so  that  the  state  within  a  shared  region  is  protected  at  the  granularity 
of  the  subregions  of  the  original  region.  For  our  example,  this  means  replacing  the  protection 
of  the  single  region  Instance  by  the  protection  of  the  two  subregions  Queue  and  Listeners. 
The  transformation  associated  new  lock  objects  with  subregions  and  introduces  the  appropriate 
annotations  to  reflect  the  modified  design  intent.  A  precondition  of  the  transformation  is  that  all 
subregions  arc  identified  with  a  final  field  of  the  class  or  the  instance’s  receiver  to  provide  the 
lock  object  to  be  used  to  protect  the  subregion.  For  our  example,  the  object  referred  to  by  the  field 
listeners  will  protect  region  Listeners,  and  the  object  referred  to  by  the  field  queue  will 
protect  region  Queue. 

Generally,  the  code  is  changed  as  follows.  (1)  All  the  critical  sections  for  the  lock  being  split 
arc  identified  via  use  of  the  @lock  annotations.  (2)  Effects  analysis  is  used  to  identify  the  most 
specific  regions  affected  by  the  critical  section.  (3)  The  subregions  of  the  original  region  affected 
by  the  critical  section  determine  how  the  critical  section  is  modified  to  use  the  new  region-lock  as¬ 
signments.  For  example,  the  body  of  method  addEQListener  has  the  effect  reads  Listeners, 
so  it  is  modified  to  lock  on  listeners  instead  of  this.  In  a  similar  manner,  the  @requiresLock 
annotations  arc  updated.  The  modified  EventQueue  class  is  shown  in  Figure  8.2. 
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1  /**  @region  public  Listeners 

2  *  @region  public  Queue 

3  *  @lock  Lock  is  this  protects  Instance  */ 

4  public  final  class  EventQueue  { 

5  /**  @unshared 

6  *  ©aggregate  Instance  into  Listeners  */ 

7  private  final  List  listeners; 

8  /**  @unshared 

9  *  ©aggregate  Instance  into  Queue  */ 


10 

11 

12 

13 

14 

private  final  List  queue; 

/**  @mapInto  Queue  */ 
private  int  len; 

public  EventQueue ( )  { 

15 

listeners  =  new  ArrayListO; 

16 

queue  =  new  LinkedList ( ) ; 

17 

len  =  0 ; 

18 

} 

19 

20 

/**  @writes  Listeners  */ 

21 

public  synchronized  void  addEQListener (  EQListener  1 

22 

23 

/**  @writes  Listeners  */ 

24 

public  synchronized  void  removeEQListener ( 

EQListener 

25 

26 

/**  @writes  All 

27 

*  @requiresLock  Lock  */ 

28 

private  void  fireEQEvent(  Object  o  )  { 

29 

List  copy  =  (List) ( (ArrayList) listeners) 

.  clone ( ) ; 

30 

f or (  int  i  =  0;  i  <  copy. size () ;  i++  )  { 

31 

final  EQListener  1  =  (EQListener) copy . 1 

get (  i  )  ; 

32 

1 . dequeued (  o  ) ; 

33 

} 

34 

} 

35 

36 

/**  @reads  Queue  */ 

37 

public  synchronized  int  getSizeO  {  return 

len;  } 

38 

39 

/**  @writes  Queue  */ 

40 

public  synchronized  void  enqueue (  Object  o 

)  { 

41 

queue . add (  o  ) ; 

42 

len  +=  1; 

43 

} 

44 

45 

/**  @writes  Queue 

46 

*  @requiresLock  Lock  */ 

47 

private  Object  dequeue ( )  { 

48 

if (  len  ==  0  )  return  null; 

49 

else  { 

50 

len  -=  1; 

51 

return  queue . remove (  0  ) ; 

52 

} 

53 

} 

54 

55 

/**  @writes  All  */ 

56 

public  synchronized  void  dispatchEvent ( )  { 

57 

final  Object  o  =  dequeue () ; 

58 

fireEQEvent(  o  ); 

59 

} 

60 

\ 

listeners . add (  1  );  } 

{  listeners . remove (  1  );  } 


Figure  8.1:  Initial  version  of  EventQueue  that  uses  a  single  lock  to  protect  the  entire  object. 
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/**  @region  public  Listeners 

*  @region  public  Queue 

*  @lock  QLock  is  queue  protects  Queue 

*  @lock  ListLock  is  listeners  protects  Listeners  */ 

public  final  class  EventQueue  { 

/**  @unshared 

*  ©aggregate  Instance  into  Listeners  */ 

private  final  List  listeners; 

/**  @unshared 

*  ©aggregate  Instance  into  Queue  */ 

private  final  List  queue; 

/**  @mapInto  Queue  */ 
private  int  len; 

public  EventQueue ( )  { 

listeners  =  new  ArrayListO; 
queue  =  new  LinkedList ( ) ; 
len  =  0 ; 

} 

/**  @writes  Listeners  */ 

public  void  addEQListener (  EQListener  1  )  {  synchronized!  listeners  )  { 

/**  @writes  Listeners  */ 

public  void  removeEQListener (  EQListener  1  )  {  synchronized!  listeners 


/**  @writes  All 
*  @requiresLock  ListLock  */ 

private  void  f ireEQEvent (  Object  o  )  { 

List  copy  =  (List) ( (ArrayList) listeners) .clone!) ; 
for!  int  i  =  0;  i  <  copy. size!) ;  i++  )  { 

final  EQListener  1  =  (EQListener) copy .get (  i  ); 
1 . dequeued (  o  ) ; 


/**  @reads  Queue  */ 

public  int  getSize!)  {  synchronized!  queue  )  {  return  len;  }  } 

/**  @writes  Queue  */ 

public  void  enqueue!  Object  o  )  { 
synchronized!  queue  )  { 
queue . add (  o  ) ; 
len  +=  1; 


/**  @writes  Queue 
*  @requiresLock  QLock  */ 

private  Object  dequeue!)  { 
if (  len  ==  0  )  return  null; 
else  { 

len  -=  1; 

return  queue . remove (  0  ) ; 


/**  @writes  All  */ 

public  void  dispatchEvent ( )  { 
synchronized!  queue  )  { 

synchronized!  listeners  )  { 
final  Object  o  =  dequeue!); 
f ireEQEvent!  o  ); 


listeners . add (  1  );  }  } 

)  {  listeners . remove (  1  );  }  } 


Figure  8.2:  EventQueue  after  the  split-lock  modification.  Differences  from  Figure  8.1  are  under¬ 
lined. 
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8.2.2  Shrink  Critical  Section 


Another  concurrency-related  modification  is  to  shrink  the  computational  scope  of  a  critical  section. 
In  general,  applying  this  modification  to  a  set  of  locks  would  identify  the  synchronized  statements 
that  use  those  locks,  and  for  each  one,  alter  the  lexical  positions  of  the  beginning  and  ending  of  the 
critical  sections  in  the  program  text  to  remove  any  statements  that  do  not  affect  the  region  associated 
with  the  critical  section’s  lock.  For  example,  applying  it  to  class  EventQueue  in  Figure  8.2  for 
QLock  and  ListLock  would  only  affect  one  method,  dispatchEvent,  transforming  it  to  be 

1  /**  @writes  All  */ 

2  public  void  dispatchEvent ( )  { 

3  Object  temp; 

4  synchronized (  queue  )  {  temp  =  dequeue ();  } 

5  final  Object  o  =  temp; 

6  synchronized (  listeners  )  {  f ireEQEvent (  o  );  } 

7  } 


because  method  dequeue  only  requires  the  caller  to  hold  QLock  and  method  f  ireEQEvent  only 
requires  the  caller  to  hold  ListLock.  Because  there  are  no  direct  effects  on  the  regions  Queue 
and  Listener  in  dispatchEvent,  the  analysis  supporting  the  transformation  makes  use  of  the 
@requiresLock  annotations  on  the  methods  dequeue  and  f  ireEQEvent. 


8.2.3  Problems 

A  moment’s  thought  on  the  results  of  shrinking  the  critical  sections  in  dispatchEvent  produces 
the  conclusion  that  EventQueue  is  now  broken:  the  first-in-first-out  behavior  that  made  it  a  queue 
has  been  compromised.  By  moving  the  calls  of  dequeue  and  f  ireEQEvent  into  separate  criti¬ 
cal  sections,  we  have  enabled  the  following  scenario.  Assume  there  arc  at  least  two  events  in  an 
EventQueue  eq,  and  that  no  other  threads  arc  concurrently  accessing  eq: 

1.  One  thread  invokes  dispatchEvent,  which  executes  through  line  5. 

2.  Now  a  second  thread  invokes  dispatchEvent.  Because  the  first  thread  is  not  in  a  critical 
section,  the  second  thread  can  begin  to  execute  the  method,  and,  in  fact,  executes  the  method 
in  its  entirety. 

3.  The  first  thread  resumes  execution,  completing  line  6. 

This  scenario  causes  events  to  be  sent  to  listeners  out  of  order,  a  violation  of  the  intended  first-in- 
first-out  behavior  of  the  queue. 
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8.2.4  Missing  Policy 


Our  application  of  the  shrink  critical  section  transformation  did  not  execute  safely  because  it 
caused  the  class  to  change  its  behavior  in  a  manner  contrary  to  the  intent  of  the  programmer.  Clearly 
its  preconditions  need  to  be  improved:  the  transformation  must  respect  the  relevant  programmer- 
defined  concurrency  policies.  In  this  case,  the  programmer  needs  to  specify  a  policy  that  forbids 
dispatchEvent  to  interleave  with  itself  so  that  the  FIFO  nature  of  the  queue  is  maintained.  Now 
shrink  critical  section  will  unnest  the  two  critical  sections  in  dispatchEvent,  but  also  introduce 
the  usage  of  a  new  policy  lock  to  prevent  the  possibility  that  the  method  could  interleave  with  itself. 
The  resulting  method  implementation  is 

/**  @writes  All  */ 

public  void  dispatchEvent ( )  { 

synchronized (  this  )  { 

Object  temp; 

synchronized (  queue  )  {  temp  =  dequeue () ;  } 
final  Object  o  =  temp; 

synchronized (  listeners  )  {  f ireEQEvent (  o  );  } 


8.3  Evolving  a  Priority  Event  Queue 

We  now  consider  a  concrete  example  of  the  role  of  concurrency  policy  in  transformations  by  evolv¬ 
ing  an  elaborated  version  of  the  EventQueue  class,  shown  in  Figure  8.3.  The  EventQueue  now 
contains  two  channels — a  priority  and  a  normal  channel — each  of  which  behaves  as  a  distinct  queue. 
When  the  EventQueue  needs  to  broadcast  an  event,  it  always  tries  to  send  a  priority  event;  only 
if  no  such  event  is  available  is  a  normal  event  dequeued.  The  state  of  instances  of  the  class  is  now 
divided  into  three  subregions:  Listeners,  Normal,  and  Priority.  The  fields  of  EventQueue 
arc  distributed  among  these  regions:  listeners  into  Listeners,  normal  and  numNormal  into 
Normal,  and  high  and  numHigh  into  Priority. 

8.3.1  The  Initial  Policy  and  EventQueue 

Figure  8.4  shows  class  EventQueue  from  Figure  8.3  transformed  to  be  concurrent  using  make 
thread  safe.  As  with  the  previous  example,  a  new  annotation  is  introduced  declaring  that  this 
is  used  as  the  lock  to  protect  region  Instance,  and  all  the  non-private  methods  arc  made 
synchronized;  private  methods  are  annotated  with  @requiresLock  annotations.  The  ini- 
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Figure  8.3:  Initial  form  of  the  priority  EventQueue. 
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1  /**  . . . 

2  *  @lock  Lock  is  this  protects  Instance  */ 

3  public  class  EventQueue  {  ... 

4  public  EventQueue ( )  {  ...  } 

5 

6  /**  @writes  Listeners  */ 

7  public  synchronized  void  addEQListener (  EQListener  1  )  {  ...  } 

8 

9  /**  @writes  Listeners  */ 

10  public  synchronized  void  removeEQListener (  EQListener  1  )  {  ...  } 

11 

12  /**  @writes  All 

13  *  @requiresLock  Lock  */ 

14  private  void  fireEQEvent(  EQEvent  e  )  {  ...  } 

15 

16  /**  @reads  Normal,  Priority  */ 

17  public  synchronized  int  getSizeO  {  ...  } 

18 

19  /**  @writes  Normal  */ 

20  public  synchronized  void  enqueue (  EQEvent  e  ) 

21  throws  NullPointerException  {  ...  } 

22 

23  /**  @writes  Priority  */ 

24  public  synchronized  void  enqueuePriority (  EQEvent  e  ) 

25  throws  NullPointerException  {  ...  } 

26 

27  /**  @writes  Normal,  Priority 

28  *  @requiresLock  Lock  */ 

29  private  EQEvent  dequeue ( )  {  ...  } 

30 

31  /**  @writes  Normal 

32  *  @requiresLock  Lock  */ 

33  private  EQEvent  dequeueNormal ( )  {  ...  } 

34 

35  /**  @writes  Priority 

36  *  @requiresLock  Lock  */ 

37  private  EQEvent  dequeuePriority ( )  {  ...  } 

38 

39  /**  @writes  All  */ 

40  public  synchronized  void  dispatchEvent ( )  {  ...  } 

41  } 


Figure  8.4:  Class  EventQueue  after  being  made  concurrent.  Differences  from  Figure  8.3  are  un¬ 
derlined. 


tial  internal  concurrency  policy  forbids  any  non-private  method  to  interrupt  any  other.  The  class 
is  obviously  consistent  with  this  policy. 


8.3.2  Enabling  Liberalized  Policy  Specification  for  EventQueue 

Before  the  internal  concurrency  policy  of  EventQueue  can  be  liberalized,  the  class  must  be  modi¬ 
fied  to  reduce  the  granularity  of  the  data  protections.  The  split  lock  transformation  is  applied  to  the 
class,  so  that  the  regions  Listeners,  Normal,  and  Priority  are  separately  protected;  the  objects 
referred  to  by  the  fields  listeners,  normal,  and  high  are  used  as  the  new  locks,  respectively. 
Unlike  the  preliminary  example  in  Section  8.2,  transformation  does  not  remove  the  synchronized 
declarations  from  the  non-private  methods.  To  do  so  would  cause  the  class  to  violate  its  internal 
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concurrency  policy.  The  resulting  class  is  shown  in  Figure  8.5;  notice  that  this  has  been  turned 
into  a  policy  lock.  The  scopes  of  the  critical  sections  generated  by  the  split  lock  transformation 
arc  then  shrunk  by  performing  a  shrink  critical  sections  transformation.  The  results  arc  shown  in 
Figure  8.6. 

Now  that  EventQueue  has  methods  with  more  than  one  critical  section,  it  is  possible  to  consider 
how  its  internal  concurrency  policy  might  be  liberalized.  Here  we  consider  the  reasoning  about 
internal  policy  based  on  existing  state -based  critical  sections.  These  are  abstracted  in  Figure  8.7. 
In  particular,  we  consider  how  a  critical  section  for  region  R  in  one  method  might  observe  changes 
made  in  a  critical  section  for  R  in  a  concurrently  executing  method,  and  how  this  observation  may 
violate  higher-level  design  intentions  regarding  the  behavior  of  the  methods.  Methods  getsize 
and  dispatchEvent  have  potentially  interesting  interleavings  with  other  methods  because  they 
have  multiple  critical  sections.  We  consider  the  derivation  of  two  different  internal  polices,  though 
more  arc  possible:  (1)  getsize  always  returns  a  value  that  is  greater  than  or  equal  to  the  actual 
size  of  the  queue  at  the  time  the  method  returns;  and  (2)  getsize  always  returns  a  value  that  is  less 
than  or  equal  to  the  actual  size  of  the  queue  at  the  time  the  method  returns.  Both  policies  insure  that 
events  arc  dispatched  in  the  same  order  they  arc  enqueued,  and  that  if  a  normal  event  is  dispatched, 
the  queue  does  not  contain  a  priority  event  when  dispatchEvent  returns. 

8.3.3  Maximizing  getsize 

The  policy  matrix  describing  the  maximizing  internal  concurrency  policy  is  shown  in  Figure  8.8. 
The  methods  addEQListener  and  removeEQListener  do  not  affect  the  contents  of  the  queue, 
i.e.,  the  regions  Normal  and  Priority,  so  their  effects  on  policy  development  arc  not  discussed. 
Let  us  consider  explicitly  the  remaining  pairwise  cases. 

Method  getsize  and  itself 

Two  calls  to  getsize  could  interleave  in  one  of  two  ways:  (1)  PfJS \ ;  P&S2;  Ngsi;  NgS2  and  (2) 
Pgsi;  Pg.s2 :  Ng,S2 :  Ngs | .  Because  getsize  only  reads  data,  it  cannot  interfere  with  itself,  and  we 
thus  allow  it  to  execute  concurrently  with  itself. 


Figure  8.5:  Class  EventQueue  after  a  split-lock  transformation.  Differences  from  Figure  8.4  arc  underlined. 
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1  public  class  EventQueue  {  ... 

2  public  EventQueue ( )  {  ...  } 

3 

4  /**  @reads  Normal,  Priority  */ 

5  public  synchronized  int  getSizeO  { 

6  int  n,  h; 

7  synchronized (  normal  )  {  h  =  numHigh;  } 

8  synchronized (  high  )  {  n  =  numNormal;  } 


9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 


return  n  +  h; 

} 


/**  @writes  Normal  */ 

public  synchronized  void  enqueue (  EQEvent  e  )  throws  NullPointerException  { 
if (  e  ==  null  )  { 

throw  NullPointerException (  "Cannot  enqueue  null"  ); 

}  else  { 

synchronized (  normal  )  { 
normal . add (  e  )  ; 
numNormal  +=  1; 


/**  @writes  Priority  */ 

public  synchronized  void  enqueuePriority (  EQEvent  e  )  throws  NullPointerException 
if (  e  ==  null  )  { 

throw  NullPointerException (  "Cannot  enqueue  null"  ); 

}  else  { 

synchronized (  high  )  { 
high . add (  e  ) ; 
numHigh  +=  1; 


/**  @writes  All  */ 

public  synchronized  void  dispatchEvent ( )  { 

EQEvent  e  =  null; 
synchronized (  high  )  { 

synchronized!  normal  )  {  e  =  dequeue!);  } 

} 

if(  e  !=  null  )  synchronized!  listeners  )  {  f ireEQEvent (  e  );  } 

} 


{ 


Figure  8.6:  Class  EventQueue  after  a  shrink-critical-sections  transformation.  Differences  from 
Figure  8.5  are  underlined. 


Method 

Critical  Sections 

addEQListener 

L 

removeEQListener 

L 

getSize 

P ;  N 

enqueue 

N 

enqueuePriority 

P 

dispatchEvent 

P(N)  ;  L 

Figure  8.7:  Critical  sections  accessed  by  EventQueue’s  methods  in  Figure  8.6.  L,  N,  and  P  represent 
critical  sections  for  regions  Listeners,  Normal,  and  Priority,  respectively.  Sequential  accesses 
are  separated  by  a  ‘ ;  ’.  Nested  accesses  arc  notated  within  parentheses. 
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Figure  8.8:  The  internal  concurrency  policy  for  maximizing  get  size. 


Methods  getSize  and  enqueue 

A  call  to  enqueue  could  interleave  with  getSize  in  exactly  one  way:  Pgs ;  Ne;  NgS.  Because 
getSize  would  read  the  number  of  normal  events  in  critical  section  after  it  is  incremented  in 
Ne,  it  would  return  the  exact  size  of  the  queue.  This  is  consistent  with  our  intended  semantics  for 
getSize  so  we  allow  the  interleaving. 

Methods  getSize  and  enqueuePriority 

A  call  to  enqueuePriority  could  interleave  with  getSize  in  exactly  one  way:  P^;  Pep;  NgS. 
Because  getSize  would  read  the  number  of  priority  events  in  Pgs  just  prior  to  it  being  incremented 
in  Pep,  which  happens  before  the  method  returns,  it  would  return  a  size  that  is  smaller  than  the  actual 
size  of  the  queue  at  the  point  in  time  that  the  method  returns.  We  decide,  therefore,  to  disallow  the 
possibility  of  enqueuePriority  interleaving  with  getSize. 

Methods  getSize  and  dispatchEvent 

Assuming  a  thread  is  already  executing  getSize,  a  concurrent  call  to  dispatchEvent  could  in¬ 
terleave  with  getSize  in  three  ways:  (1)  Pgs)  P(fe(Ngs)  Nde);  L de,  (2)  Pgs;  Pde(Nrfe);  NgS;  L^e,  and 
(3)  Pgs;  Pde(Nde);  L,y ;  NgS.  In  all  cases,  the  number  of  priority  events  in  the  queue  could  be  decre¬ 
mented  after  getSize  reads  the  number  of  priority  events,  and  thus  the  number  of  normal  events  in 
the  queue  read  by  getSize  would  always  be  exact  because  it  is  read  after  dispatchEvent  might 
have  altered  it.  Under  these  conditions,  getSize  will  always  return  either  the  exact  size  or  a  size 
greater  than  the  actual  size  of  the  queue  at  the  point  in  time  when  it  returns. 

We  have  considered  how  dispatchEvent  could  “interrupt”  execution  of  getSize.  Now  we 
consider  how  getSize  could  “interrupt”  execution  of  dispatchEvent.  The  possible  interleavings 


8.3.  EVOLVING  A  PRIORITY  EVENT  QUEUE 


185 


are:  Prfe(Nde);  P,,.s;  Ngs ;  Lde  and  Pde(Nde);  Pgs ;  Lde;  N^.1  In  both  cases,  getsize  will  read  the 
sizes  of  the  two  portions  of  the  queue  after  dispatchEvent  will  have  made  any  modifications, 
and  thus  getsize  will  always  return  the  exact  size  of  the  queue  at  the  point  in  time  it  returns. 

We  decide  therefore  that  the  two  methods  arc  allowed  to  interleave. 

Methods  dispatchEvent  and  enqueue 

These  methods  can  interleave  in  two  ways:  (1)  Pde(Ne;  N^e);  Lde  and  (2)  Pffe(Nde);  Ne;  Lde?  In  the 
first  case,  the  normal  event  will  be  enqueue  before  dispatchEvent  may  attempt  to  dequeue  one.  In 
the  second  case,  because  the  event  is  enqueued  after  the  attempt  to  dequeue  one,  dispatchEvent 
may  return  without  having  dispatched  any  events  even  though  it  is  returning  when  there  is  an  event 
in  the  queue.  For  the  purposes  of  our  example,  we  decide  that  this  is  acceptable  behavior,  so  allow 
the  methods  to  interleave. 

Methods  dispatchEvent  and  enqueuePriority 

There  is  only  one  possible  interleaving:  P,;r  ( N^e ) :  Pep;  Lde.  This  scenario  can  result  in  the  dispatch 
of  a  normal  event  even  though  a  priority  event  is  available  so  we  decide  to  disallow  this  interleaving. 

Method  dispatchEvent  and  itself 

Finally,  we  consider  how  dispatchEvent  could  interleave  with  itself.  The  possible  interleavings 
are:  (1)  Pi(Ni);  P2(N2);  Li;  L2  and  (2)  Pi(Ni);  P2(N2);  L2;  Li.  The  first  trace  is  allowable,  but 
the  second  trace  would  cause  an  event  to  be  sent  out  of  order,  and  thus  must  be  disallowed.  We, 
therefore,  disallow  dispatchEvent  from  interleaving  with  itself. 

8.3.4  Minimizing  getsize 

We  now  consider  how  to  specify  the  policy  that  insures  getsize  will  always  return  a  size  that  is 
less  than  or  equal  to  the  actual  size  of  the  queue  at  the  point  in  time  that  getsize  returns.  The 
policy  matrix  describing  this  minimizing  policy  is  shown  in  Figure  8.9.  We  describe  only  the  two 
cases  for  which  the  policy  decisions  arc  different  from  the  maximizing  case. 

'Critical  section  N9,s  cannot  interleave  with  N^e  nested  inside  of  P de,  because  critical  section  P3S  must  execute  before 
Ngs,  and  must  appear  after  P de  has  executed  in  its  entirety. 

2 This  is  equivalent  to  Pde(Nde;  Ne);  Lde. 
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Figure  8.9:  The  policy  matrix  for  minimizing  getsize.  Differences  from  Figure  8.8  arc  boxed. 


1.  The  programmer  can  allow  enqueuePriority  to  interrupt  getsize.  As  is  previously  men¬ 
tioned,  there  is  only  one  interleaving:  Pgs ;  Pep;  N,/iS.  Because  the  number  of  priority  events  in 
the  queue  is  increased  after  the  number  of  priority  events  in  the  queue  is  read,  getsize  will 
return  a  size  that  is  too  small  at  the  point  in  time  when  it  returns.  This  is  consistent  with  the 
minimizing  policy. 

2.  The  programmer  must,  however,  disallow  dispatchEvent  from  interrupting  getsize.  Be¬ 
cause  it  is  previously  argued  that  this  interruption  can  cause  getsize  to  return  a  size  that 
is  larger  than  the  actual  size  at  the  point  in  time  that  it  returns,  this  interruption  is  clearly 
contrary  to  the  desired  minimizing  policy. 

8.3.5  A  Note  on  Policy  Elicitation 

The  specification  of  policy  is  grounded  in  the  programmer’s  notion  of  how  the  program  should 
behave.  We  expect  that,  in  practice,  interactive  tools  will  elicit  policy  specifications  from  the  pro¬ 
grammer  by  asking  precise  questions  based  on  existing  critical  sections  and  inferred  interleaving 
possibilities  about  which  method  interactions  arc  allowed.  In  this  regal'd,  the  programmer  does  not 
have  to  worry  about  the  behavior  until  asked  about  it  by  the  tool. 

8.3.6  Implementing  Policy 

The  process  of  liberalizing  a  policy  specification  does  not  alter  the  source  code.  The  implement 
policy  transformation  is  used  to  update  the  code  to  take  advantage  of  a  new  internal  policy.  Con¬ 
sidering  a  method-based  policy  representation,  one  approach  to  this  transformation  is  to  associate 
a  new  lock  with  each  method  that  is  not  allowed  to  interleave  with  some  other  method,  or  more 


8.4.  POLICY  SPECIFICATION  AND  TRANSFORMATION  (REPRISE) 


187 


concretely,  to  associate  a  new  policy  lock  with  each  method  whose  column?  in  the  policy  matrix 
contains  a  “x If  method  m  has  a  new  policy  lock  associated  with  it,  the  bodies  of  method  m  and  of 
each  method  n  that  must  not  interleave  with  it  are  wrapped  in  synchronized  blocks  that  acquire 
the  lock  associated  with  m.  This  locking  replaces  any  previous  policy-based  locking. 

Figure  8.10  shows  EventQueue  after  being  transformed  to  take  advantage  of  the  maximiz¬ 
ing  getsize  policy.  The  policy  lock  Serial  (formerly  represented  by  this)  has  been  replaced 
by  the  policy  locks  GSLock,  represented  by  the  new  field  gsLock,  and  DLock,  represented  by 
this,  which  prevent  methods  from  interleaving  with  getsize  and  dispatchEvent,  respec¬ 
tively.  The  body  of  method  getsize  is  within  a  block  synchronized  on  gsLock.  This  pre¬ 
vents  enqueuePriority,  which  also  synchronizes  on  gsLock,  from  interrupting  its  execution. 
The  body  of  method  dispatchEvent  synchronizes  on  this,  which  prevents  dispatchEvent 
from  interrupting  itself.  The  implementation  is  still  more  conservative  than  policy  allows:  method 
getsize  is  allowed  to  interrupt  itself,  but  the  implementation  prevents  this  due  to  the  use  of 
gsLock  within  getsize. 


8.4  Policy  Specification  and  Transformation  (Reprise) 

When  a  class  is  initially  made  concurrent,  it  is  assigned  a  conservative  concurrency  policy  requiring 
all  the  methods  of  class  to  execute  serially.  The  class  will  already  be  in  compliance  with  the  policy: 
all  bodies  of  all  its  visible  methods  will  be  declared  synchronized.  The  policy  cannot  yet  be 
liberalized  because  each  method  only  contains  one  critical  section  on  the  same  shared  region.  To 
liberalize  the  policy,  the  protection  of  data  within  the  class  needs  to  be  restructured  by  introduc¬ 
ing  new  shared  regions.  This  restructuring  is  based  on  the  region  hierarchy  within  the  class:  finer 
grained  shared  regions  generally  enable  interleavings  at  a  finer  granularity  of  computation.  Sev¬ 
eral  source-level  manipulations  assist  the  programmer  with  this  restructuring.  For  example,  split 
lock  distributes  locking  responsibility  across  the  sub-regions  of  a  formerly  singularly  protected 
super-region.  Another  transformation,  shrink  critical  section,  uses  effects  analysis  to  contract  the 
syntactic  scope  of  a  critical  section  by  moving  its  beginning  and  end  past  statements  that  do  not 
affect  the  region  being  protected  by  the  critical  section. 

The  initial  definition  of  regions  within  the  class  reflects  the  programmer’s  understanding  of  how 
fields  of  the  class  are  related.  In  particular,  concurrency  opportunities  are  introduced  or  eliminated 

3We  could  just  as  easily  associate  a  lock  with  a  row,  the  point  here  is  to  introduce  only  one  lock  for  each  pair  of 
methods  that  must  not  execute  interleaved. 


Figure  8.10:  Final  liberalized  implementation  of  EventQueue. 
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according  to  the  programmer’s  notion  of  how  the  different  regions  of  state  arc  related,  and  the 
end  policy  that  the  programmer  intends  to  specify.  For  example,  in  EventQueue,  we  adopted  a 
policy  that  allows  for  operations  on  listeners  to  execute  concurrently  with  the  manipulation  of  queue 
items.  The  protection  of  listeners,  therefore,  was  separated  from  the  protection  of  queue  elements. 
Similarly,  because  we  wanted  to  be  able  to  concurrently  enqueue  both  a  normal  and  a  high-priority 
event,  the  protection  of  the  two  queue  segments  was  made  distinct.  If  we  did  not  need  to  be  able  to 
manipulate  both  kinds  of  events  simultaneously,  there  would  be  no  benefit,  from  the  point  of  view 
of  policy,  gained  from  making  distinct  regions  for  normal  and  high-priority  events. 

Once  the  protection  of  state  has  been  restructured,  the  policy  specification  can  be  liberalized. 
If  a  liberal-enough  policy  is  not  specifiable,  there  arc  two  options.  The  programmer  can  repeat  the 
process  of  altering  the  structure  of  shared  regions  to  expose  more  potential  concurrency  within  the 
methods.  If  this  restructuring  is  not  possible,  or  the  additional  concurrency  results  in  behavior  that 
violates  the  intended  behavior  of  the  class,  then  the  programmer  may  have  to  reconsider  the  desired 
behavior.  Such  reconsiderations  arc  translated  into  policy  by  enabling  pairs  of  methods  to  interleave 
that  were  previously  not  allowed  to  interleave. 

The  internal  concurrency  policy  of  a  class  influences  which  transformations  may  be  applied  to 
the  code:  modifications  that  would  enable  the  class  to  behave  contrary  to  the  policy  arc  meant  to 
be  disallowed.  It  is  important  to  recognize  that  in  our  generative  approach  the  policy  evolves  along 
with  the  program.  A  policy  might  be  initially  restrictive;  as  the  programmer  determines  that  various 
transformations  should  be  applied  to  the  program,  the  policy  can  be  relaxed — if  the  programmer  de¬ 
cides  that  relaxing  the  policy  is  acceptable — to  enable  them.  Once  a  satisfactory  policy  is  specified, 
the  implementation  of  the  class  can  be  transformed  to  take  advantage  of  newly  allowable  concur¬ 
rency.  Of  course,  it  should  also  be  possible  to  evolve  the  policy  to  be  more  restrictive.  This  presents 
more  difficulty,  and  may  best  be  addressed  by  first  retreating  to  a  previous  state  of  development  that 
employs  a  more  restrictive  policy  than  the  one  desired. 


8.5  The  Split  Lock  Transformation 

Split  lock  is  parameterized  by  the  @lock  annotation  of  the  lock  to  be  split,  giving  a  lock  L  with 
name  M  associated  with  a  shared  region  R.  The  lock  annotations  within  the  class  arc  analyzed  to 
determine  all  the  subregions  R\..  .  .  .  R.n  of  R.  For  each  child  region  Rt,  the  programmer  is  asked 
to  provide  a  new  mutex  name  Mt,  and  to  identify  a  final  field  of  the  class  or  this  to  be  used  as 
the  lock  representation  F,  for  that  region. 
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We  first  describe  the  transformation  ignoring  the  existence  of  @requiresLock  annotations.  All 
the  method  and  constructor  bodies  of  the  class  arc  searched  to  find  all  the  synchronized  blocks 
that  use  lock  L.  For  each  such  synchronized  block,  the  transformation 

•  Determines  the  child  regions  { Ilj }  of  R  that  arc  affected  by  the  body.  Effects  outside  of 
region  R  arc  not  interesting.  The  exact  child  regions  of  R  that  are  affected  can  be  determined 
because  the  exact  fields  affected  arc  known;  any  field  affecting  region  It  is  either  a  member 
of  a  child  of  R,  or  is  itself  a  child  of  R. 

•  Replaces  the  synchronized  block  with  a  set  of  nested  synchronized  blocks  that  acquire 
the  appropriate  locks  { Lj }  for  the  regions  { Il:j } . 

The  class  is  also  modified  by  the  addition  and  removal  of  annotations: 

•  The  original  @lock  annotation  is  removed. 

•  Any  annotations  @returnsLock  M  arc  removed — it  ought  to  be  the  case  that  any  method 
so  annotated  no  longer  has  any  callsites. 

•  For  each  child  region  It,  of  R,  a  new  lock  declaration  is  added  to  the  class 

@lock  Mi  is  Fi  protects  Ri 

8.5.1  Handling  @requiresLock  Annotations 

The  easiest  way  to  deal  with  @requiresLock  annotations  is  to  replace  any  appearance  of  M  in 
them  with  M\, . . .  ,  Mn.  This  is  always  correct,  and  does  not  interfere  with  existing  uses  of  the 
methods.  This  would  be  done  before  modifications  are  made  to  any  synchronized  blocks.  This 
approach,  however,  can  unnecessarily  constrain  the  future  use  of  the  methods  because  they  would 
require  more  locks  than  they  may  actually  need.  The  difficulty  in  making  the  annotations  less 
restrictive  is  discerning  the  programmer’s  intent :  the  programmer  might  want  to  use  less  general 
annotations  to  preserve  flexibility  for  future  uses  of  the  method.  Analysis  of  the  implementation 
of  the  method  can  be  used  to  determine  the  new  minimum  @requiresLock  annotations  needed 
for  all  the  methods  currently  using  M.  Such  an  analysis  would  need  to  be  iterative,  because  the 
annotations  on  one  method  affect  the  annotations  on  the  methods  that  call  it.  The  tool  would  then 
present  the  minimum  annotations  to  the  user,  who  could  then  enlarge  them  if  desired. 
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8.5.2  Policy  Issues 

Currently,  policy  locks  arc  always  acquired  before  locks  associated  with  regions.  So,  while  any 
synchronized  statement  replaced  by  split  lock  that  occurs  within  a  synchronized  statement 
acquiring  a  policy  lock  can  affect  the  interleavings  that  arc  exposed  when  policy  is  defined,  it  will 
not  alter  the  interleavings  that  could  actually  occur  at  runtime.  Altered  synchronized  blocks  that 
do  not  appeal-  within  policy-related  synchronized  blocks  can  affect  the  interleavings  that  may 
occur  at  runtime.  For  example,  after  applying  split  lock,  two  critical  sections  that  formerly  acquired 
a  lock  L  may  now  acquire  locks  M  and  N,  respectively.  These  two  critical  sections  no  longer 
exclude  each  other,  and  their  concurrent  execution  may  produce  effects  contrary  to  the  desired 
concurrency  policy.  To  prevent  the  current  policy  from  being  violated,  therefore,  a  new  policy  lock 
needs  to  be  declared  in  the  class  and  new  synchronized  blocks  that  acquire  it  must  be  placed 
around  any  synchronized  blocks  introduced  by  the  manipulation  that  are  not  otherwise  within 
policy-related  synchronized  blocks. 


8.6  The  Shrink  Critical  Section  Transformation 

In  its  most  basic  form,  shrink  critical  section  operates  on  a  single  synchronized  block,  limiting 
its  effects  to  a  single  method.  The  transformation  changes  the  syntactic  size  of  a  critical  section;  a 
different  transformation  is  used  to  split  a  single  critical  section  into  multiple  critical  sections.  Com¬ 
pound  variations  of  the  transformation  can  be  assembled  that  would  shrink  all  the  critical  sections 
of  a  particular  shared  region  within  a  method,  class,  or  subtree  of  the  class  hierarchy,  or  that  shrink 
all  the  critical  sections  within  a  method,  class,  or  subtree  of  the  class  hierarchy. 

Shrink  critical  section  takes  as  input  a  single  synchronized  block.  The  block’s  expression 
must  be  a  final  expression  so  that  the  lock  being  used  can  be  identified;  see  Section  5.6.  From  the 
lock,  the  shared  region  being  protected  can  be  determined.  This  operation  cannot  be  applied  to  a 
policy  lock. 

It  seems  that  this  should  be  an  easy  transformation  to  perform:  the  effects  of  the  statements  in 
the  synchronized  block  could  be  used  to  move  the  start  and  end  of  the  block  past  statements  that 
do  not  have  effects  on  the  shared  region  it  is  protecting.  In  addition,  the  synchronized  block 
could  be  moved  inside  of  a  compound  statement  if  that  statement  is  the  only  remaining  content  of 
the  synchronized  block.  There  are  many  complicating  factors,  however: 

•  The  order  of  nested  synchronized  statements  cannot  be  changed  because  of  deadlock  con- 
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cerns. 

•  The  bounds  of  a  synchronized  block  cannot  be  moved  across  looping  constructs.  This 
would  split  the  critical  section.  Introducing  new  critical  sections  alters  how  methods  can 
interleave,  and  would  affect  policy. 

•  switch  statements  arc  problematic  because  some  cases  might  “fall  through”  to  others, 
which  could  also  cause  the  possibility  of  split  critical  sections. 

In  short,  the  transformation’s  preconditions,  particularly  those  concerning  policy  arc  complicated, 
and  require  further  research. 


8.7  Developing  the  Generative  Approach 

The  current  presentation  is  of  a  notional  generative  approach  to  concurrency  management:  we  have 
not  yet  implemented  any  transformations.  Before  we  can  implement  a  transformation,  the  precise 
details  of  its  specification  must  be  elaborated:  what  are  its  preconditions,  how  does  it  use  analysis 
and  annotation,  how  does  it  appeal  to  the  concurrency  policy,  what  exactly  does  it  do  to  the  source 
code,  what  arc  the  caveats  of  a  successful  transformation,  etc.  In  addition,  the  concurrency-related 
transformations  mentioned  so  far  consider  only  a  single  final  class,  and  affect  only  the  number, 
scope,  and  granularity  of  critical  sections  used  by  its  method  implementations.  These  kinds  of 
manipulations  relate  to  how  an  object  can  be  manipulated  by  multiple  threads.  Transformations 
that  introduce  the  definition  and  use  of  threads  arc  missing,  as  arc  manipulations  that  introduce  and 
evolve  the  use  of  condition  variables.  Additional  work  is  needed  to  understand  what  form  these 
manipulations  should  take,  and  what  their  effects  should  be.  These  techniques  can  also  be  extended 
to  transform  non-final  classes. 

The  generative  approach  could  be  expanded  to  handle  the  evolution  of  confederations  of  in¬ 
stances  that  cooperate  in  their  use  of  concurrency;  e.g.,  a  class  that  uses  delegates  that  is  intended  to 
appear  to  be  a  single  monitor.  Transformations  that  can  introduce  and  evolve  such  relationships  need 
to  be  identified,  but  first  our  understanding  of  the  nature  of  collaborations  needs  to  be  improved. 


8.8  Related  Work 

Several  areas  of  research  are  related  to  our  proposed  transformation-based  approach  to  concurrency. 
In  this  section  we  first  discuss  Andrews’s  global  invariant  approach  to  the  development  of  correct 
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concurrent  programs  in  which  the  programmer  designs  a  program  first  at  a  coarse  granularity  of 
atomicity,  then  at  a  finer  granularity,  and  finally  converts  the  design  into  a  specific  implementa¬ 
tion.  We  next  review  previous  transformational  approaches  to  converting  sequential  programs  into 
correct  concurrent  programs.  Finally,  we  review  literature  on  compiler-based  transformations  that 
optimize — generally  by  attempting  to  minimize  the  number  of  critical  sections — the  acquisition  of 
locks. 

8.8.1  The  Global  Invariant  Approach 

Andrews’s  global  invariant  approach,  introduced  in  [And89]  and  elaborated  in  [And91],  is  a  sys¬ 
tematic  method  for  solving  synchronization  problems  based  on  viewing  processes  as  invariant  main- 
tamers.  Maintainence  of  the  invariant  insures  that  the  processes  arc  interference-free.  The  method 
consists  of  four  steps:  (1)  define  the  problem,  (2)  outline  a  solution,  (3)  ensure  the  invariant,  and  (4) 
implement  the  atomic  actions.  In  the  first  step  the  processes  arc  identified  as  sequential  algorithms, 
and  the  invariant  is  specified  over  shared  state.  This  state  is  often  introduced  solely  to  represent  ex¬ 
plicitly  information  about  the  processes  that  is  otherwise  unrelated  to  the  underlying  computation, 
such  as  the  number  of  proceseses  currently  executing  a  critical  section.  Follow  up  work  [MizOla], 
discussed  below,  identifies  many  common  invariant  patterns  that  simplifies  this  process  and  frees 
the  programmer  from  having  to  introduce  variables  for  such  accounting  purposes.  In  the  second 
step,  the  programmer  introduces  assignments  to  the  shared  variables  so  that  the  invariant  is  initially 
true  and  groups  assignments  into  atomic  actions. 

In  the  third  step,  the  programmer  guards  each  atomic  assignment  as  necessary  to  insure  that  the 
state  resulting  from  the  assignment  statisfies  the  invariant.  The  necessary  guards  can  be  mechan¬ 
ically  derived  using  Dijkstra’s  weakest  precondition.  Finally,  the  in  the  fourth  step,  the  guarded 
atomic  statements  arc  implemented  on  top  of  an  underlying  synchronization  mechanism  such  as 
semaphores  or  monitors.  More  recently,  Mizuno  describes  how  to  perform  the  fourth  step  for  Java 
[Miz99].  His  translation  presents  a  solution  to  the  problem  of  using  multiple  condition  variables 
associated  with  a  single  mutex  in  Java,  while  making  efficient  use  of  notification. 

The  second  and  third  steps  are  mechanical  once  the  invariant  is  identified  in  the  first  step.  Re¬ 
cently  published  refinements  to  the  process  and  recently  developed  tool  support  make  the  fourth 
step  mechanical  as  well.  Mizuno,  et  al.  [MizOlb]  have  integrated  Andrews’s  basic  method  into 
scenario-based  development  methologies,  such  as  the  Unified  Modeling  Language  and  Rational 
Unified  Process,  and  incorporated  it  into  an  aspect-oriented  programming  [  KLM!  97  ]  framework. 
Specification  of  the  invariant  and  the  associated  synchronization  described  in  a  synchronization  as- 
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pect  distinct  from  the  sequential  implementation  of  processes.  Use-case  realizations,  made  up  of, 
for  example,  sequence  diagrams,  collaboration  diagrams,  and  scenarios,  describe  the  collaborations 
between  classes  and  objects  in  the  system.  The  developer  identifies  synchronization  regions  in  sce¬ 
narios.  “A  synchronization  region  is  a  segment  in  a  scenario  (1)  in  which  a  thread  waits  for  some 
event  to  occur  or  some  state  to  hold  ...  and  (2)  in  which  a  thread  may  trigger  an  event  or  change  a 
state  for  which  a  thread  at  some  other  synchronization  region  is  waiting.”  The  reflexive  transitive 
closure  of  the  relation  between  communicating  regions  defines  equivalence  classes  called  clusters. 
The  developer  identifies  a  global  invariant  for  each  cluster.  Course-grained  and  fine-grained  solu¬ 
tions  follow,  except  that  they  describe  only  the  entry  and  exit  points  to  each  cluster.  A  final  weaving 
step  integrates  the  fine-grained  synchronization  aspect  with  the  component  code  developed  from  the 
scenarios. 

The  primary  difficulty  of  the  global  invariant  approach  is  identifying  appropriate  invariants. 
Mizuno  [MizOla]  describes  a  useful  set  of  global  invariant  patterns  that  can  be  composed  to  suc- 
cintly  and  more  easily  specifiy  global  invariants  for  clusters.  The  patterns  arc  all  defined  in  terms 
of  “in”  and  “out”  counters  that  track  the  number  of  threads  that  have  entered  and  exited  a  synchro¬ 
nization  region. 

Deng,  el  al.  [DDHM02]  implement  the  aspect-oriented  synchronization  approach  for  C++  and 
Java  in  the  SyncGen  tool.  The  programmer  identifies  synchronization  regions  and  clusters  in  the 
core  functional,  i.e.,  non-synchronization  code,  using  annotations.  The  programmer  specifies  a  syn¬ 
chronization  invariant  for  each  cluster  using  conjunctions  of  invariant  patterns.  The  global  invari¬ 
ants  arc  automatically  translated  into  implementation-independent  coarse-grained  solutions.  Sync- 
Gen  can  translate  the  coarse-grained  solution  into  implementation-specific  fine-grained  solutions 
for  Java,  C,  and  C++  environments  and  weave  the  synchronization  code  with  the  core  functional 
implementation.  A  final  model-checking  step  uses  the  Bandera  framework  [CD1T  00]  to  verify  the 
translation  process. 

8.8.2  Sequential  to  Concurrent  Programs 

In  Path  Pascal  [CK79],  the  programmer  writes  objects  in  a  purely  sequential  manner.  Allowable 
concurrency  is  specified  separately,  as  the  class’s  path  expression.  Every  method  must  appear  at  least 
once  in  the  path  expression,  which  specifies  the  relationships  among  the  methods  in  the  class.  For 
example,  a  relative  order  of  execution  among  a  set  of  methods  can  be  specified,  a  set  of  methods  can 
be  made  mutually  exclusive,  or  the  number  of  active  executions  of  a  given  method  can  be  limited. 
Rules  to  generate  method  prologues  and  epilogues  that  make  use  of  counting  semaphores  from  the 
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the  path  expression  arc  provided.  Path  expressions  also  require  that  the  ability  of  a  method  to  run 
depend  only  on  what  other  methods  are  currently  executing  or  have  executed;  it  can  not  depend 
on  the  current  state  of  the  object.  The  purpose  of  path  expressions  is  to  encapsulate  the  abstract 
relationship  between  methods,  separate  from  the  methods’  implementations.  The  preservation  of 
data  invariants  is  accomplished  solely  through  the  specification  of  the  path  expression  for  a  class; 
there  is  no  such  thing  as  a  critical  section,  and  therefore,  there  is  no  way  to  identify  statement-level 
parallelism. 

Wu  and  Lewis  [WL90]  apply  path  expressions  to  C++  objects  to  describe  the  legal  concurrent 
executions  of  methods  of  that  object.  By  checking  uses  of  objects  of  the  class  against  the  path 
expression,  illegal  concurrent  uses  of  the  class  can  be  statically  identified.  Instead  of  translating 
the  path  expression  into  code  that  implements  the  policy,  they  use  an  algorithm  based  on  data  de¬ 
pendence  information  and  the  path  expression  to  identify  regions  of  code  that  can  be  automatically 
parallelized  because  it  is  known  that  the  parallelized  code  will  invoke  methods  in  a  manner  that 
respects  the  path  expression. 

Sims  and  Hensgen  [SH93]  describe  how  to  automatically  convert  a  sequential  object  to  a  con¬ 
current  object  that  uses  two-phased  locking.  The  concurrent  object  will  be  free  of  race  conditions 
and  deadlock.  The  technique  allows  for  unrelated  methods  to  execute  concurrently.  Unfortunately, 
they  omit  the  details  of  how  to  determine  what  locks  arc  needed,  and  what  state  the  locks  are  actually 
protecting. 

Herlihy  [Her91]  describes  a  technique  for  transforming  a  sequential  implementation  of  a  data 
structure  into  a  wait-free  and  non-blocking  concurrent  data  object.  The  sequential  implementation 
is  not  general,  but  written  with  the  transformation  in  mind.  The  non-blocking  transformation  is 
based  on  being  able  to  copy  object  state.  Objects  arc  divided  into  blocks  of  state,  and  the  sequential 
implementation  is  not  allowed  to  modify  anything  other  than  the  blocks  making  up  the  object.  Each 
operation  supported  by  the  object  must  be  well  defined  for  every  legal  state  of  the  object.  For  objects 
that  occupy  more  than  one  block,  efficiency  is  increased  by  only  copying  those  blocks  of  the  object 
that  arc  changed  by  an  operation.  This  must  be  done  by  the  implementor  who  must  write  each 
operation  in  a  functional  style.  Instead  of  modifying  the  blocks  directly,  a  method  returns  a  new  set 
of  blocks  representing  the  new  state  of  the  object.  The  actual  transformation  from  sequential  object 
to  wait-free,  non-blocking  concurrent  object  is  mechanical,  and  is  intended  to  be  performed  by  a 
pre -processor  or  compiler. 

Alemany  and  Felten  [AF92]  and  Barnes  [Bar93]  have  followed  up  on  Herlihy’s  work,  but  are 
mainly  concerned  with  improving  the  bounds  on  the  execution  time.  Barnes’s  work  does  allow 
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for  concurrent  modification  of  objects  under  some  circumstances,  but  requires  that  the  original 
sequential  operations  be  specifically  written  in  such  a  way  that  they  can  cooperate. 

8.8.3  Compiler  Optimizations 

Plevyak,  Zhang,  and  Chien  [PZC95]  describe  optimizations  that  a  compiler  can  perform  on  con¬ 
current  object-oriented  languages.  In  the  runtime  system  they  optimize  for,  every  object  has  its 
own  lock  to  implement  access  control  on  its  own  state.  They  focus  on  inlining  method  calls  to 
expose  critical  sections  that  can  be  merged.  An  inlined  method  call  can  execute  only  if  any  locks 
that  it  requires  are  not  held.  Methods  identified  for  inlining,  therefore,  arc  replaced  with  a  condi¬ 
tional  statement:  the  true  branch  contains  the  inlined  method  surrounded  by  code  that  acquires  and 
releases  the  necessary  locks;  the  false  branch  invokes  the  method  normally.  The  expression  that 
checks  if  runtime  conditions  permit  inlining  together  with  the  true  branch  of  the  conditional  arc 
known  as  an  access  region.  The  focus  of  their  work  is  the  enlargement  of  access  regions  to  reduce 
the  overhead  of  critical  sections.  Access  regions  arc  expanded  by  moving  code  into  the  true  branch 
of  the  conditional,  and  by  merging  adjacent  access  regions;  new,  empty  access  regions  can  also  be 
introduced,  and  then  populated  by  expansion. 

Mutual  exclusion  is  maintained  by  only  expanding  access  regions  to  include  statements  whose 
locking  conditions  arc  subsumed  by  those  of  the  access  region,  and  by  insuring  that  when  storage 
accesses  for  the  same  object  from  two  distinct  access  regions  arc  moved  into  the  same  region, 
they  “occur  in  whole,  before  or  after  each  other,  ensuring  locally  the  mutual  exclusion  that  the 
programming  model  guarantees.”  Deadlock  introduction  is  prevented  by  disallowing  a  statement 
that  may  block  on  a  resource  from  being  moved  into  an  access  region.  Also,  when  an  empty  access 
region  is  created,  all  locks  are  acquired  atomically  (i.e.,  either  all  the  locks  or  none  of  the  locks  are 
acquired);  this  prevents  new  resource  dependencies,  and  thus  new  sources  of  deadlock,  from  being 
introduced. 

Diniz  and  Rinard  [DR96]  present  two  compiler  optimizations  that  decrease  the  granularity  of 
locks  used  in  automatically  parallelized  object-oriented  programs.  Every  object  originally  has  its 
own  lock,  which  is  acquired  whenever  data  in  that  object  is  accessed.  Data  lock  coarsening ,  asso¬ 
ciates  a  single  lock  with  a  set  of  objects  that  arc  used  together.  This  is  similar  to  using  regions  with 
uniqueness  aggregation  in  our  system.  They  avoid  the  aliasing  issue  by  restricting  the  use  of  the 
classes  of  nested  objects.  Computation  lock  coarsening  transforms  a  computation  that  repeatedly 
acquires  and  releases  the  same  lock  into  a  computation  that  acquires  and  releases  the  lock  only  once. 
The  algorithm  they  present  for  data  lock  coarsening  attempts  to  protect  nested  objects  with  the  same 
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lock  as  their  enclosing  object,  and  results  in  the  introduction  of  synchronized  and  synchronization- 
free  versions  of  methods.  Computation  lock  coarsening  is  performed  after  data  lock  coarsening,  and 
can  be  applied  to  a  method  if  (1)  it  does  not  contain  concurrency  introducing  constructs,  (2)  only 
accesses  data  in  its  receiver  and  the  nested  objects  of  the  receiver,  and  (3)  all  the  methods  of  nested 
objects  that  it  invokes  arc  protected  by  the  method’s  receiver’s  lock.  Computation  lock  coarsening 
alters  the  method  so  that  its  first  statement  acquires  the  lock,  its  last  statement  releases  the  lock,  and 
its  method  calls  only  invoke  synchronization-free  methods.  Data  lock  coarsening  cannot  introduce 
deadlock  because  the  original  execution  model  dictates  that  no  method  of  enclosing-class  C  can  be 
called  when  locks  are  held,  and  methods  of  C  will  only  ever  obtain  a  single  lock.  Computation  lock 
coarsening  does  not  introduce  deadlock  because  it  only  replaces  repeated  acquisitions  of  the  same 
lock  with  a  single  acquisition  of  the  lock  for  a  longer  period  of  time. 

In  follow-up  work  [DR97],  Diniz  and  Rinard  describe  generic  techniques  for  increasing  the 
size  of  critical  sections  that  replace  their  previous  lock  coarsening  techniques.  Their  goal  is  to 
remove  synchronization  by  eliminating  adjacent  mutex  acquire  and  release  operations.  Acquires 
and  releases  arc  first  made  adjacent  by  enlarging  the  size  and  scope  of  critical  sections:  acquires 
arc  moved  ’"upwards”  along  the  control  flow  graph,  while  releases  arc  moved  ’’downwards”  along 
the  control  flow  graph.  A  mutex  acquisition  can  be  moved  upwards,  past  a  node  n  that  has  multiple 
predecessor  nodes.  In  this  case,  the  acquisition  is  duplicated  across  all  entries  into  n,  and  releases  arc 
inserted  along  all  paths  out  of  n  except  for  the  one  from  which  the  acquisition  originated.  Similarly, 
a  release  can  be  moved  downwards,  past  a  node  with  multiple  successors.  The  compiler  identifies 
pairs  of  acquire  and  release  operations  to  move  based  on  reachability  within  the  control  flow  graph. 
Movement  and  cancellation  of  acquires  and  releases  arc  applied  in  one  step  based  on  the  intersection 
of  reachability  paths  in  the  control  flow  graph.  The  process  is  repeated  until  it  cannot  be  applied 
any  more;  termination  is  assured  because  the  critical  sections  can  only  become  bigger.  To  prevent 
the  introduction  of  deadlock,  a  mutex  operation  is  not  allowed  to  be  moved  past  a  statement  that 
is  already  in  a  critical  section.  The  order  in  which  critical  sections  arc  nested  is,  therefore,  never 
altered. 
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Conclusion 


The  failure  to  express  concurrency-related  models  impedes  programmer  understanding,  explicit  as¬ 
surance  of  safety,  and  the  safe  evolution  of  concurrent  programs.  In  particular,  the  design  intent 
describing  intended  implementation  properties  is  usually  missing,  and  it  is  generally  impossible  to 
assure  that  an  implementation  conforms  to  the  programmer’s  intent,  e.g.,  is  free  of  race  conditions. 
Experience  has  shown  that  it  is  difficult  to  safely  evolve  a  program  without  an  explicit  expression 
of  these  models.  In  general,  current  programming  languages  and  processes  do  not  facilitate  the 
capture  of  program  design  information  in  ways  that  arc  usable — and  adoptable — by  practicing  pro¬ 
grammers.  Nor  do  current  tools  readily  provide  the  means  to  assure  that  captured  design  information 
is  consistent  with  source  code  and  vice  versa.  As  a  result,  design  information  may  be  lost  or  out  of 
sync  with  the  reality  of  the  code,  obscuring  the  implementation  properties  to  be  assured. 

In  this  dissertation,  we  present  a  programmer-oriented  approach  to  safe  concurrency  in  which 

•  Models  of  programmer  design  intent  arc  described  using  formal  program  annotations  con¬ 
cerning  mechanical  program  properties. 

•  Consistency  between  source  code  and  annotated  design  intent  is  assured  using  composable 
static  analyses  supported  by  an  iterative  programmer-led  process. 

A  dominant  design  consideration  for  our  approach  is  adoptability  by  practicing  programmers,  which 
influences  the  design  of  our  annotations  and  of  our  prototype  analysis  tool.  In  particular,  we  con¬ 
sider  that,  at  the  present  state  of  capability,  it  is  generally  unreasonable  to  require  programmers  to 
explicitly  express  representation  invariants.  Instead,  we  ask  the  programmer  to  record  design  intent 
in  terms  of  properties  the  programmer  is  already  concerned  about.  In  addition  to  being  easier  for  the 
programmer  express,  these  “mechanical”  annotations  provide  value  beyond  enabling  tool-assisted 
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assurance  by  answering  design-related  questions  a  programmer  reading  the  source  code  might  ask. 
Specifically,  we  use  annotations  to  express  the  following  model  elements: 

•  To  name  and  hierarchically  organize  the  state  of  a  program,  with  aggregates  that  may  span 
multiple  objects. 

•  To  describe  which  state  is  affected  by  a  method  (or  other  code  segment),  and  what  is  the 
nature  of  the  effects. 

•  To  identify  uniqueness  of  object  references,  modulo  temporary  “borrowed”  references. 

•  To  associate  locks  with  abstract  aggregations  of  state,  and  provide  names  for  the  locks. 

•  To  delineate  responsibility  for  acquiring  locks  (e.g.,  caller  vs.  callee). 

•  To  specify  which  methods  may  be  executed  concurrently. 

Adoptability  strongly  influences  the  design  of  analysis  approach  via  the  principle  of  “early  grat¬ 
ification.”  Some  assurance  can  be  obtained  with  minimal  or  no  annotation  effort,  and  additional 
increments  of  annotation  arc  rewarded  with  additional  increments  of  assurance. 


9.1  Summary  of  Contributions 

This  dissertation  is  about  (1)  the  consequences  of  missing  design  intent,  (2)  capturing  programmer 
design  intent  via  mechanical  program  annotations,  (3)  using  static  analysis  to  assure  consistency 
between  source  code  and  intent,  and  (4)  doing  it  in  a  way  that  is  practicable  for  working  program¬ 
mers.  Concurrency  provides  an  excellent  problem  domain  because  concurrent  programs  have  so 
many  unexpressed  design  commitments  that  arc  not  local  to  any  particular  segment  of  code,  and  the 
consequences  of  errors  in  concurrent  programs  can  lead  to  security  and  reliability  faults.  Our  overall 
goals  arc  to  improve  program  quality  by  enabling  analyses  that  assure  the  safety  of  programs  (with 
respect  to  expressed  design  intentions),  and  to  enable  safe  program  evolution,  eventually  through  the 
use  of  tool-supported  program  transformations.  New  technical  and  engineering  results  contributed 
by  this  dissertation  include: 

•  Regions  provide  flexible  encapsulations  of  object  state.  Specifically,  they  provide  a  hierarchi¬ 
cal  covering  of  the  notional  state  of  an  object,  enabling  state  to  be  named  at  different  gran¬ 
ularities.  State  aggregations  can  cross  object  boundaries  by  (1)  the  exploitation  of  unshared 
(unaliased)  references  and  (2)  the  parameterization  of  classes  by  regions,  enabling  parts  of 
objects  to  be  owned  by  other  objects. 

•  We  describe  an  object-oriented  effects  system  based  on  the  state  named  by  regions. 
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•  We  explicitly  associate  locks  with  regions  to  protect  shared  state.  Similar  approaches  in 
the  literature  either  lack  a  state  model,  or  use  ownership-based  models  that  arc  incapable 
protecting  state  at  tine  granularity  or  incorporating  only  a  portion  of  an  object  into  another 
object. 

•  Our  notion  of  concurrency  policy  enables  concise  descriptions  of  allowable  method  interleav¬ 
ings.  In  particular,  concurrency  policy  is  a  surrogate  for  unstated  representations  that  still 
allows  the  programmer  to  differentiate  between  “good”  and  “bad”  concurrency.  Furthermore, 
it  explicitly  expresses  to  clients  of  a  class  its  intended  concurrent  behavior. 

•  Static  analyses  for  assuring  the  consistency  between  source  code  and  expressed  effect-  and 
concurrency-related  design  intent. 

•  The  beginnings  of  an  incremental  tool-supported  process  for  inserting,  assuring,  and  ex¬ 
ploiting  annotations  expressing  models  of  state  and  concurrency  properties.  Specifically,  we 
implemented  a  set  of  Eclipse  plug-ins  providing  a  prototype  tool  for  assuring  that  Java  pro¬ 
grams  arc  consistent  with  their  associated  concurrency-related  models.  Our  tool  goes  beyond 
“bug  hunting”  by  providing  both  explicit  positive  and  negative  assurance  results;  similar  tools 
in  the  literature  arc  interested  primarily  in  negative  results  and  arc  typically  incapable  of  pro¬ 
viding  positive  assurance. 

•  A  notional  generative  approach  to  concurrency  management  in  which  semantics-based,  be¬ 
havior  preserving,  source-level  program  transformations  arc  used  to  evolve  the  amount  of 
concurrency  in  a  program,  allowing  the  exploration  of  policy  and  other  design  decisions  while 
keeping  program  complexity  manageable.  In  particular,  our  hierarchical  model  of  state  en¬ 
ables  easy  exploration  of  the  granularity  at  which  state  is  protected.  Concurrency  policy  plays 
a  fundamental  role  in  preventing  transformations  from  modifying  the  programmer’s  design 
intent  with  respect  to  consistency  of  state. 

9.1.1  Case  Studies 

Throughout,  we  apply  our  annotation  and  assurance  techniques  to  examples  drawn  from  production 
Java  code  to  experiment  with  describing  design  intent,  providing  assurance  of  model-code  consis¬ 
tency,  and  finding  bugs.  In  addition  to  demonstrating  the  applicability  of  our  approach  to  production 
Java  code,  our  case  studies  with  our  prototype  assurance  tool  in  Eclipse  demonstrate  the  incremen- 
tality  of  our  approach,  and  provide  informal  evidence  that  we  are  providing  “early  gratification.” 
For  example, 
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•  We  capture  the  models  of  state  and  locking  intent  for  the  BoundedFlFO  class  from  the  Jakarta 
Log4j  library.  Using  our  prototype  assurance  tool,  we  arc  able  to  assure  that  (1)  the  imple¬ 
mentation  of  BoundedFlFO  and  (2)  the  implementation  of  a  client  of  BoundedFlFO  are 
consistent  with  these  models.  No  modifications  to  the  original  source  code  were  required 
beyond  the  introduction  of  our  annotations.  We  show  how  we  can  express  both  the  internal 
and  external  concurrency  policies  for  the  class.  In  addition,  we  demonstrate  notionally  how 
the  design  intent  captured  by  our  annotations  can  be  exploited  to  preserve  the  safety  of  the 
class  during  an  actual  evolution  scenario. 

•  We  express  the  state  aggregation  and  locking  intent  for  the  pair  of  classes  ThreadCache  and 
CachedThread  from  the  W3C  Jigsaw  web  server.  In  particular,  the  complexities  of  state  in 
this  example  cannot  be  expressed  by  similar  approaches  and  tools  in  the  literature. 

•  We  show  how  to  derive  and  express  the  internal  and  external  concurrency  policies  of  the  class 
AppenderAttachablelmpl  from  Log4j,  uncover  a  policy  mismatch  error  between  the  class 
and  its  clients,  and  describe  how  a  notional  tool  could  assist  in  the  discovery  of  this  error.  This 
error  was  reported  to  the  maintainers  of  the  library  and  resulted  in  a  bug  fix. 

•  We  capture  the  models  of  state  and  locking  intent  for  the  Logger  class  from  the  Java  JDK 
j  ava .  util .  logging  package.  Using  our  prototype  tool,  we  incrementally  and  interactively 
introduce  annotations  into  the  source  code,  receiving  additional  assurance  results  at  each 
step.  This  process  required  hypothesizing  about  actual  programmer  design  intent,  and  making 
minor  modifications  to  the  source  code.  We  discover  a  previously  unreported  race  condition, 
and  identify  several  areas  of  questionable  design  intent. 

More  generally,  an  inspection  of  the  JDK  packages  j  ava  .util,  j  ava .  lang,  and  j  ava .  awt .  *, 
and  java .  io  indicates  that  our  tool  and  techniques  are  sufficient  to  find  and  explain  known  con¬ 
currency  errors:  both  race  conditions  and  policy  violations. 


9.2  Looking  Forward 


Possible  future  directions  for  this  work  include:  expressing  and  assuring  additional  concurrency- 
related  design  intent,  expressing  patterns  of  concurrency,  incorporating  diagrammatic  models  of 
intent,  and  annotation  management. 
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9.2.1  Additional  Concurrency-Related  Models 

This  dissertation  focuses  on  concurrency-related  models  related  to  shared-memory  concurrency  pro¬ 
gramming.  in  particular  models  related  to  the  integrity  of  state.  Specific  concurrency  concerns  not 
addressed  in  this  work  include  reader-writer  locks,  deadlock,  condition  variables,  and  thread  iden¬ 
tification. 

Greater  amounts  of  concurrency  can  be  obtained  by  using  reader-writer  locks,  a  form  of  mutex 
that  distinguishes  between  read  and  write  operations.  Multiple  threads  can  acquire  the  lock  to  obtain 
read  permission  while  excluding  any  threads  that  want  to  acquire  write  access,  while  exactly  one 
thread  at  a  time  can  acquire  the  lock  to  obtain  write  access.  Java  does  not  natively  support  reader- 
writer  locks,  but  objects  providing  such  functionality  can  be  written  and  arc  provided  by  most 
concurrency  utility  libraries,  e.g.,  [Lea],  Reader-writer  locks  present  several  additional  assurance 
challenges.  We  must  assure  that  critical  sections  intended  to  only  read  state  do  not  modify  the  state. 
Our  effects  system  makes  this  straightforward,  modulo  aliasing  concerns.  Because  lock  acquisition 
and  release  are  based  on  distinguished  method  calls,  we  must  assure  that  locks  arc  properly  released 
at  the  close  of  critical  sections.  In  general,  this  is  an  object  protocol  problem,  e.g.,  [Nie93],  but  a 
specialized  analysis  for  the  particular  situation  is  straightforward  to  implement,  cf.  Warlock  [Ste93]. 
We  already  describe  how  concurrency  policy  can  describe  reader-writer  design  intent. 

It  is  well  known  that  annotations  specifying  and  managing  partial  orders  for  lock  acquisition 
can  assist  in  assuring  deadlock  freedom.  These  annotations  arc  global  in  character,  but  can  be  made 
incrementally,  /.<?.,  by  adding  new  pairs  to  the  partial  order  relation.  A  more  challenging  ordering 
problem  is  ordering  the  instances  of  a  class:  this  is  important,  for  example,  when  two  instances  must 
be  compared.  Lea  presents  a  programming  idiom  based  on  unique  resource  identifiers  to  address 
this  problem  [LeaOO] .  Boyapati,  el  al.  present  a  type  system  that  enforces  a  resource  ordering  among 
nodes  in  tree  structures,  and  that  can  even  handle  dynamic  reordering  of  nodes  in  the  tree  [BLR02] . 
Providing  and  assuring  correct  use  of  resource  orderings  among  instances  of  the  same  class  remains 
an  open  problem  in  general. 

We  have  begun  to  experiment  with  the  expression  of  design  intent  related  to  condition  variables. 
In  [NGS01],  we  describe  how  conditions  might  be  explicitly  associated  with  the  variable  used  to 
control  blocking. 

Locking  is  not  the  only  technique  for  protecting  data  in  concurrent  programs:  for  example, 
immutable  objects  can  be  shared  without  coordination  and  thread-local  objects  arc  not  shared  at  all. 
While  our  notion  of  concurrency  policy  is  capable  of  describing  some  of  the  design  intent  embodied 
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in  such  classes,  our  current  techniques  arc  not  sufficient  for  assuring  that  an  implementation  of  an 
object  is  immutable,  or  that  a  reference  does  not  escape  a  particular-  thread.  Assuring  immutability 
is  an  application  of  our  state  model  and  effects  system.  Additional  aliasing  assurances  can  assist  in 
the  problem  of  thread-locality.  In  addition,  we  are  exploring  “thread  coloring”  techniques  that  make 
explicit  the  relationship  between  threads,  data,  and  code  segments  [SGS02].  Making  thread  models 
explicit  facilitates  assurance  of  code  and  data  thread-locality,  as  well  as  the  identification  of  shared 
usage  of  state  not  intended  to  be  shared. 

9.2.2  Concurrency  Coding  Idioms 

Concurrency  is  often  used  in  a  stylized  manner,  that  is,  by  making  use  of  particular  coding  patterns, 
such  as  those  of  [LeaOO].  The  burden  of  annotating  concurrent  programs  could  be  lightened  by 
developing  annotations  that  describe  a  program's  use  of  concurrency  at  a  higher  semantic  level  that 
accounts  for  these  programming  idioms.  Examples  include  a  single  annotation  that  declares  the 
intent  that  a  class  is  intended  to  be  a  monitor,  or  an  annotation  describing  the  intent  that  a  particular 
class  is  meant  to  be  thread-safe  wrapper  around  another  class. 

9.2.3  Diagrammatic  Models 

Models  of  program  behavior  can  be  expressed  diagrammatically.  We  have  begun  to  develop  dia¬ 
grams  that  capture  and  express  concurrency-related  design  in  terms  of  mechanical  program  prop¬ 
erties  [NGS01].  Such  models  are  an  alternative  means  of  expressing  and  maintaining  programmer 
design  intent — assurance  between  annotations,  source  code,  and  diagrams  must  be  provided.  For 
example.  Figure  9.1  describes  how  concurrency  is  used  by  the  class  WakeupManager  in  Sun’s  Jini 
library,  including  how  state  is  protected,  how  locks  are  ordered,  what  are  the  conditions  used  by  the 
class,  and  which  locks  and  conditions  are  used  by  various  methods.  WakeupManager  is  a  queue  of 
time-stamped  tasks  sorted  by  deadline.  Nested  class  Kicker  implements  a  thread  responsible  for 
executing  tasks  in  the  queue  and  requires  the  locks  for  both  itself  and  the  queue  so  lock  ordering 
is  used:  ContentsLock  must  be  acquired  before  the  KickerLock.  Kicker  has  two  condition 
variables  (stop  signs  in  the  diagram):  one  to  abort,  and  one  to  signal  the  addition  of  a  new  task. 
From  the  diagram  it  is  easy  to  see  (1)  what  is  the  lock  orde,r  as  well  as  (2)  that  invoking  newTime 
may  cause  a  thread  blocked  in  run  to  unblock  by  satisfying  the  newTicket  condition. 
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Figure  9.1:  Method  concurrency  diagram  for  class  WakeupManager.  Diagram  by  Elissa  Newman. 


9.2.4  Tool  Development 

Development  of  our  prototype  assurance  tool  is  ongoing.  Active  areas  of  research  include  issues  of 
tool-programmer  interaction  and  truth  maintenance  of  assurance  results.  In  particular,  we  wish  to 
present  to  the  user  “chains  of  evidence”  that  link  together  expressed  design  intent,  analysis  results, 
and  code  segments  to  document  the  reasoning  behind  each  assurance  result,  positive  or  negative. 
While  our  current  case  studies  suggest  that  we  arc  on-track  towards  our  goal  of  providing  useful 
incremental  results  and  “early  gratification,”  formal  user  studies  arc  required  to  demonstrate  this 
property  more  formally. 
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